[Live-devel] About fixing RTSP-over-HTTP with correct HTTP protocol version

David_Yang at alphanetworks.com David_Yang at alphanetworks.com
Thu Nov 5 05:36:58 PST 2020


Dear Ross,
The easier way is to modify "HTTP/1.1" with "HTTP/1.0". Or, you may need to implement "chunk transfer encoding" in both client and server.
Here is my patch. (same as the attached)

diff -Naru live/liveMedia/RTSPClient.cpp live-patch/liveMedia/RTSPClient.cpp
--- live/liveMedia/RTSPClient.cpp2020-11-04 02:27:51.000000000 +0800
+++ live-patch/liveMedia/RTSPClient.cpp2020-11-05 21:20:52.638280301 +0800
@@ -749,7 +749,8 @@
     netAddressBits serverAddress = *(netAddressBits*)(destAddress.data());
     AddressString serverAddressString(serverAddress);

-    protocolStr = "HTTP/1.1";
+    //protocolStr = "HTTP/1.1";
+    protocolStr = "HTTP/1.0";

     if (strcmp(request->commandName(), "GET") == 0) {
       // Create a 'session cookie' string, using MD5:
diff -Naru live/liveMedia/RTSPServer.cpp live-patch/liveMedia/RTSPServer.cpp
--- live/liveMedia/RTSPServer.cpp2020-11-04 02:27:51.000000000 +0800
+++ live-patch/liveMedia/RTSPServer.cpp2020-11-05 21:16:52.661426573 +0800
@@ -483,13 +483,13 @@

 void RTSPServer::RTSPClientConnection::handleHTTPCmd_notSupported() {
   snprintf((char*)fResponseBuffer, sizeof fResponseBuffer,
-   "HTTP/1.1 405 Method Not Allowed\r\n%s\r\n\r\n",
+   "HTTP/1.0 405 Method Not Allowed\r\n%s\r\n\r\n",
    dateHeader());
 }

 void RTSPServer::RTSPClientConnection::handleHTTPCmd_notFound() {
   snprintf((char*)fResponseBuffer, sizeof fResponseBuffer,
-   "HTTP/1.1 404 Not Found\r\n%s\r\n\r\n",
+   "HTTP/1.0 404 Not Found\r\n%s\r\n\r\n",
    dateHeader());
 }

@@ -499,7 +499,7 @@
 #endif
   // Construct a response to the "OPTIONS" command that notes that our special headers (for RTSP-over-HTTP tunneling) are allowed:
   snprintf((char*)fResponseBuffer, sizeof fResponseBuffer,
-   "HTTP/1.1 200 OK\r\n"
+   "HTTP/1.0 200 OK\r\n"
    "%s"
    "Access-Control-Allow-Origin: *\r\n"
    "Access-Control-Allow-Methods: POST, GET, OPTIONS\r\n"
@@ -523,7 +523,7 @@

   // Construct our response:
   snprintf((char*)fResponseBuffer, sizeof fResponseBuffer,
-   "HTTP/1.1 200 OK\r\n"
+   "HTTP/1.0 200 OK\r\n"
    "%s"
    "Cache-Control: no-cache\r\n"
    "Pragma: no-cache\r\n"



Best regards,
David Yang 楊長葵

Digital Surveillance Software Dept. I
Alpha Networks Inc.
Tel: 886-2-77206006 ext.3858
Mobile: 886-988335406
E-mail: david_yang at alphanetworks.com

-----Original Message-----
From: live-devel <live-devel-bounces at us.live555.com> On Behalf Of live-devel-request at us.live555.com
Sent: Thursday, November 5, 2020 4:00 AM
To: live-devel at us.live555.com
Subject: live-devel Digest, Vol 204, Issue 1

Send live-devel mailing list submissions to
live-devel at lists.live555.com

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.live555.com/mailman/listinfo/live-devel
or, via email, send a message with subject or body 'help' to
live-devel-request at lists.live555.com

You can reach the person managing the list at
live-devel-owner at lists.live555.com

When replying, please edit your Subject line so it is more specific than "Re: Contents of live-devel digest..."


Today's Topics:

   1. About RTSP-over-http question (David_Yang at alphanetworks.com)
   2. Re: About RTSP-over-http question (Ross Finlayson)
   3. Re: About RTSP-over-http question (Ross Finlayson)


----------------------------------------------------------------------

Message: 1
Date: Wed, 4 Nov 2020 04:29:40 +0000
From: <David_Yang at alphanetworks.com>
To: <live-devel at us.live555.com>
Subject: [Live-devel] About RTSP-over-http question
Message-ID:
<0d56a85e21fd4b6587c4cc2ce2422374 at HQMBS2.alphanetworks.com>
Content-Type: text/plain; charset="big5"

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.

Do you think is it possible to let the community to make this change?

Best regards,
David Yang

Digital Surveillance Software Dept. I
Alpha Networks Inc.
Tel: 886-2-77206006 ext.3858
Mobile: 886-988335406
E-mail: david_yang at alphanetworks.com<mailto:david_yang at alphanetworks.com>


This electronic mail transmission is intended only for the named recipient. It contains information which may be privileged,confidential and exempt from disclosure under applicable law. Dissemination, distribution, or copying of this communication by anyone other than the recipient or the recipient's agent is strictly prohibited. If this electronic mail transmission is received in error, Please notify us immediately and delete the message and all attachments of it from your computer system. Thank you for your cooperation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20201104/4dea7860/attachment-0001.htm>

------------------------------

Message: 2
Date: Wed, 4 Nov 2020 18:03:35 +1300
From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use
<live-devel at us.live555.com>
Subject: Re: [Live-devel] About RTSP-over-http question
Message-ID: <F659DC4C-C789-411B-9BD4-9CB0D24D0382 at live555.com>
Content-Type: text/plain;charset=us-ascii



> On Nov 4, 2020, at 5:29 PM, David_Yang at 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/QuickTime
> StreamingServer-412.42/Documentation/RTSP_Over_HTTP.pdf

Yes, and we have supported this protocol (for both clients and servers) for several years.  Try it; it works.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/




------------------------------

Message: 3
Date: Wed, 4 Nov 2020 18:08:55 +1300
From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use
<live-devel at us.live555.com>
Subject: Re: [Live-devel] About RTSP-over-http question
Message-ID: <EAAAB2F7-5E73-4E4E-A1B4-4D0D27BE8E9A at live555.com>
Content-Type: text/plain;charset=utf-8



> On Nov 4, 2020, at 5:29 PM, David_Yang at 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/QuickTime
> StreamingServer-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/




------------------------------

Subject: Digest Footer

_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel


------------------------------

End of live-devel Digest, Vol 204, Issue 1
******************************************
This electronic mail transmission is intended only for the named recipient. It contains information which may be privileged,confidential and exempt from disclosure under applicable law. Dissemination, distribution, or copying of this communication by anyone other than the recipient or the recipient's agent is strictly prohibited. If this electronic mail transmission is received in error, Please notify us immediately and delete the message and all attachments of it from your computer system. Thank you for your cooperation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: live.2020.11.03.patch
Type: application/octet-stream
Size: 1971 bytes
Desc: live.2020.11.03.patch
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20201105/9b6a3ab3/attachment.obj>


More information about the live-devel mailing list