> On Nov 4, 2020, at 5:29 PM, david_y...@alphanetworks.com wrote: > > Dear Sir, > While talking about RTSP over HTTP, I think the original idea should be from > a proposal for QuickTime: > https://opensource.apple.com/source/QuickTimeStreamingServer/QuickTimeStreamingServer-412.42/Documentation/RTSP_Over_HTTP.pdf > I wonder if this protocol has been adopted as a standard (check this: > https://tools.ietf.org/html/draft-gentric-avt-rtsp-http-00) > > According the original paper, QuickTime utilize “HTTP/1.0” to define the HTTP > tunnel for the RTSP rather than “HTTP/1.1”. > However, I found in live555’s implements, both client and server use HTTP/1.1 > instead. > And, this leads a problem. In HTTP/1.1, the standard requires all the > implement should support “chunked” transfer-coding. > Please check “4.4 Message Length, item 4” in HTTP 1.1 RFC2616 as follow: > > All HTTP/1.1 applications that receive entities MUST accept the "chunked" > transfer-coding (section 3.6), thus allowing this mechanism to be used for > messages when the message length cannot be determined in advance. > > Unfortunately, the current live555 version does not support chunked > transfer-coding since the header of http tunneling marks “HTTP/1.1”. > A better way is, either live555 use HTTP/1.0 instead, or to support chunked > transfer-coding with HTTP/1.1.
Oops, I’m sorry - I didn’t read the whole of your message. Yes, if this doesn’t break anything, we can change "HTTP/1.1" to “HTTP/1.0” for both RTSP clients and servers. Please make this change in your own copy of the code, and let us know if this breaks anything. If not, I’ll make this change in the next release of the LIVE555 software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
