Hi Daniel,

This is a follow-up to an earlier thread. Couldn't reply to the last message because I was only receiving the digest.

> Looking at that old thread now, it seems I didn't get a very good answer to the 401/407 treatment and
> that disturbs me. Why is the second patch necessary?

With HTTP it is feasible for a server to provide content in case of authentication failure, like a 'no trespassing' page for example.

RTSP is different. The DESCRIBE, SETUP, PLAY is a machine-machine interaction and there is no way to sent human-readable stuff for viewing in case something is wrong. The back-end, typically a video decoder, has no way to know how to decode such content anyway because the format of the content is not specified in RTSP header responses. It is specified in the SDP that is sent in the DESCRIBE body.

But, if client can't authenticate the server must not provide the SDP because with that it is providing clues about its content. Therefore, it makes much sense for an RTSP server to always respond without a body in case of authentication failure.

Your question was whether it is not allowed to send respnse bodies in case of 401 or 407. I agree this is not clear from the RFC. Above I try to convince you why it makes no sense.

Note that the typical response does indicate there is no body. See section 4.4 of rfc2326: If the Content-Length header is absent, a length 0 must be assumed.

Below is the traffic between an authenticating RTSP server and non-authenticating, I prefixed the requests with '-':

- OPTIONS rtsp://192.168.0.25/axis-media/media.amp RTSP/1.0
- CSeq: 1

RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN
Date: Wed, 10 Sep 2014 22:16:33 GMT

- DESCRIBE rtsp://192.168.0.25/axis-media/media.amp RTSP/1.0
- CSeq: 2
- Accept: application/sdp
- If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMT

RTSP/1.0 401 Unauthorized
CSeq: 2
WWW-Authenticate: Digest realm="AXIS_00408CD7B936", nonce="000012ceY92591460e176d3cd9ed5b899e06bfda317ea6", stale=FALSE
WWW-Authenticate: Basic realm="AXIS_00408CD7B936"
Date: Wed, 10 Sep 2014 22:16:33 GMT

So, here it says by not saying a length that there is no body and libcurl should not wait for it.

Now, looking at the patch from 2011 again I think it is not good enough, although it happens to work. It shouldn't check for 401 or 407, there are many more 4xx responses for which there will be no body. It should check for a body content-length of 0 instead.

Does this clarify?

You also mentioned testing. How should a test look like? I could help with testcases and probably hardware.

Regards,

Erik

Message: 3
Date: Fri, 26 Sep 2014 13:50:11 +0200 (CEST)
From: Daniel Stenberg <daniel_at_haxx.se>
To: libcurl development <curl-library_at_cool.haxx.se>
Subject: Re: rtsp authentication not working
Message-ID: <alpine.DEB.2.00.1409261329280.23141_at_tvnag.unkk.fr>
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

On Fri, 26 Sep 2014, Erik Janssen wrote:

> http://comments.gmane.org/gmane.comp.web.curl.library/32043
>
> This e-mail to plead for inclusion of this fix in the library itself.
> With authentication-support libcurl is much nicer than live555, and
> simpler than gstreamer, for use with IP video cameras. Without, it is
> not useable. Why has it never been integrated?

I think it was never integrated primarily because nobody was around and pushed hard enough for it. We basically always have more work and stuff in the queue than what we have time for so if someone drops a ball it gets lost in the stream and we may never find it again. It happens all the time. Persistance and patience are keys.

Other common reasons include that we don't get good enough code, lack documentation and don't get tests for new things. RTSP of course generally lack in the test department and this patch was no exception which makes me more careful when considering code changes.

Looking at that old thread now, it seems I didn't get a very good answer to the 401/407 treatment and that disturbs me. Why is the second patch necessary?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html