[FFmpeg-devel] RTSP over HTTP tunnel authentication

[Martin Storsjö]

On Mon, 14 Jun 2010, Stas Oskin wrote:

> > Do you have any sample URLs that we could test this with? When testing
> > with DSS, the HTTP connection doesn't need any authentication at all,
> > instead the tunneled RTSP communication does the auth negotiation just as
> > usual.
> 
> I will send you the testing URL directly.

Great, that would help quite a bit.

> > I do agree that something like this may be needed, but I'm unsure what the
> > best way of handling it is.
> >
> > The problem is that authentication combined with (large) HTTP POSTs is
> > tricky, to say the least. Normally, one would do the whole HTTP POST,
> > sending both request header and body data, and only then you'd get the 403
> > error reply saying which auth method to use (and a potential nonce, e.g.
> > for digest auth). For this case, we would never get the 403 error telling
> > us to reauthenticate until we're finished sending the POST data.
> >
> >
> AFAIK the POST gets auth reject on first portion of data it sends.

That's quite nonstandard, as far as I know HTTP.

> > Also, copying the whole auth_state struct like this probably isn't a good
> > solution in general, since for digest auth, I'm not sure you're allowed
> > to reuse the nonces from the other request. Instead you should do a new
> > request, to get unique digest auth parameters for that connection. But
> > that would require using Expect: 100-continue, which can't be relied upon.
> >
> >
> This the exact behavior I seen with other RTSP implementations, notably
> Live555. They typically re-use the auth header for POST as well. As in
> FFMPEG it pretty tricky to get the priv_data->buffer outside, copying the
> auth_state was the next best alternative as FFMPEG auth routines would
> calculate exactly same header.

Reusing the auth header only works for basic auth. For digest auth, it's 
just plain wrong.

// Martin