This looks like a fine start!

I arbitrarily chose 4000 as a number for the test

That's fine. The test numbers don't mean anything, they just make each test has its own unique id.

With respect to the libcurl check itself, notice that the code currently also includes the ugly workaround that until 7.78.0 still got RTSP authentication working. Not sure if this should be removed in the finalized test

I don't see why we would want "an ugly workaround" in the test? Especially since the test doesn't run OK with it either in current master.

In my mind, the point with this test case was to use it as a tool to verify that whatever fix is necessary to get RTSP + auth to work actually works. Without workarounds.

I don't see why we would want "an ugly workaround" in the test? Especially since the test doesn't run OK with it either in current master.

In my mind, the point with this test case was to use it as a tool to verify that whatever fix is necessary to get RTSP + auth to work actually works. Without workarounds.

Makes sense! I only added it to highlight what caused it to break from previous versions (where the workaround helped), and how without the workaround both still failed because of a deeper issue. I'll get rid of it shortly.

There's been a month with nobody trying to actually fix these problems that this test highlights.

I think we basically have two options on how to proceed in spite of no one fixing RTSP:

1. Close this PR and just leave it for later until someone tries to get things working again
2. Merge it in a disabled status, to enable it at a later point once someone gets going with RTSP

Thoughts?

I don't have a strong opinion on either, if not that merging it (even with a disabled state) might help people be aware of pending tests that need fixing. Of course there are other places where the existence of this problem is reported, so it's not really needed I guess. Sorry if I haven't worked on a fix myself in the meanwhile, but unfortunately I'm not familiar with the curl internals, at least not at the depth fixing this problem would probably need. Should that change I'll definitely take a look.

Hi,

Using @lminiero's test I have this now:

test 4000...[RTSP Authentication check]
--pd---e-v- OK (1   out of 1  , remaining: 00:00, took 1.968s, duration: 00:01)
TESTDONE: 1 tests were considered during 2 seconds.
TESTDONE: 1 tests out of 1 reported OK: 100%

but I have not fixed the CURLOPT_REDIR_PROTOCOLS problem. I did:

1. Add back to the test: test_setopt(curl, CURLOPT_REDIR_PROTOCOLS, CURLPROTO_RTSP);
2. Patched rtsp_do() to set the first_host, first_remote_port and first_remote_protocol fields

I added the diff for 2) below. I don't see how I can propose a change to a pull request. What do you think of it?

@bagder, would it be acceptable to have rtsp authentication working again, with enabled test, but accept the CURLOPT_REDIR_PROTOCOLS workaround? To me it seems of great value
Btw, I see no need for setting CURLOPT_HTTP09_ALLOWED

Below the diff for rtsp.c. @lminiero, maybe you can add it?

diff --git a/lib/rtsp.c b/lib/rtsp.c
index 6d3bf97e6..30505cd7c 100644
--- a/lib/rtsp.c
+++ b/lib/rtsp.c
@@ -267,6 +267,18 @@ static CURLcode rtsp_do(struct Curl_easy *data, bool *done)
   rtsp->CSeq_sent = data->state.rtsp_next_client_CSeq;
   rtsp->CSeq_recv = 0;
 
+  if(!data->state.first_host) {
+    /* Set first_remote_port like Curl_http_host(). Needed for correct
+     * evaluation by Curl_auth_allowed_to_host() in vauth/vauth.c
+     */
+    data->state.first_host = strdup(conn->host.name);
+    if(!data->state.first_host)
+      return CURLE_OUT_OF_MEMORY;
+
+    data->state.first_remote_port = conn->remote_port;
+    data->state.first_remote_protocol = conn->handler->protocol;
+  }
+
   /* Setup the 'p_request' pointer to the proper p_request string
    * Since all RTSP requests are included here, there is no need to
    * support custom requests like HTTP.

@bagder, would it be acceptable to have rtsp authentication working again, with enabled test, but accept the CURLOPT_REDIR_PROTOCOLS workaround? To me it seems of great value

Great value for whom? If we accept that hack to get RTSP auth working, then applications using other schemes suddenly unwillingly also start accepting redirects to RTSP URLs. That seems totally wrong.

Not to mention that if we accept this hack, I fear that every RTSP user will be happy and satisfied and no one will work on doing the proper fix.

So no, I don't think it is in the project's long-term interest to accept this work-around.

So no, I don't think it is in the project's long-term interest to accept this work-around.

I understand your reasoning. I'd appreciate if the test in this PR gets merged then in disabled status. It helps with trying to fix the redirect-thing

Great value for whom?

I mentioned that :)

I just created #9870 which is my take on fixing this. It includes this test case, renumbered to 3100 and @janssen70's clue about the first host fields.