[FFmpeg-devel] RTSP over HTTP tunnel authentication

[Ronald S. Bultje]

Hi Martin,

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?

Ronald