[FFmpeg-devel] RTSP over HTTP tunnel authentication

[Martin Storsjö]

On Mon, 21 Jun 2010, Ronald S. Bultje wrote:

> On Sun, Jun 20, 2010 at 6:13 AM, Martin Storsj? <martin at martin.st> wrote:
> > 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.
> 
> Hm... If others are OK with this then it's fine for now, until we
> start needing it. Can you add a setter as Luca suggested?

Applied with a slightly less ugly setter, thanks!

// Martin