[FFmpeg-devel] RTSP over HTTP tunnel authentication

[Martin Storsjö]

On Sat, 19 Jun 2010, Ronald S. Bultje wrote:

> On Fri, Jun 18, 2010 at 3:35 AM, Martin Storsj? <martin at martin.st> wrote:
> > Ronald, Luca, any opinions?
> [..]
> > @@ -1616,6 +1616,24 @@ redirect:
> >          ff_http_set_headers(rtsp_hd_out, headers);
> >          ff_http_set_chunked_transfer_encoding(rtsp_hd_out, 0);
> >
> > +        /* Copy the authentication state to the POST session. The HTTP
> > +         * protocol doesn't properly handle multi-pass authentication for
> > +         * POST requests, since it would require one of the following:
> > +         * - implementing Expect: 100-continue, which many HTTP servers
> > +         *   don't support anyway, even less the RTSP servers that do HTTP
> > +         *   tunneling
> > +         * - sending the whole POST data until getting a 403 reply specifying
> > +         *   what authentication method to use, then resending all that data
> > +         * - waiting for potential 403 replies directly after sending the
> > +         *   POST header (waiting for some unspecified time)
> > +         * Therefore, we copy the full auth state, which works for both basic
> > +         * and digest. (For digest, we would have to synchronize the nonce
> > +         * count variable between the two sessions, if we'd do more requests
> > +         * with the original session, though.)
> > +         */
> > +        memcpy(ff_http_get_auth_state(rtsp_hd_out),
> > +               ff_http_get_auth_state(rtsp_hd), sizeof(HTTPAuthState));
> > +
> >      } else {
> >          /* open the tcp connection */
> >          ff_url_join(tcpname, sizeof(tcpname), "tcp", NULL, host, port, NULL);
> 
> That's a little ugly, as the comment says also. Should HTTPAuthState
> be a pointer that we can set or change? Anyone else have better ideas
> here? This is all a little hacky...

Sharing the auth state would be the correct approach generally, but if 
doing it properly, it would need to be reference counted, or we'd need to 
take care that the URLContext owning the auth state be kept alive until 
all other users of the state are closed.

Also, the only cases where a HTTP URLContext does more requests is:
- on 401 responses, that is followed by a new request with the auth method 
  suggested in the 401 response
- on redirects
- on seeks

The first two only happen on startup, and we don't do any seeks on the 
tunneling streams.

So given this, I think this is quite ok to do it this way for now.

// Martin