rtsp通過代理上的http

我想通過使用代理的HTTP獲取RTSP流。 Real客戶端的行爲似乎有點緊張：它一次嘗試所有可能的端口，方法和協議。唯一可行的是通過端口80的HTTP GET。這樣的請求確實發出，並在服務器上被接收。下面是當它由代理向服務器發送請求的外觀：rtsp通過代理上的http

GET /SmpDsBhgRl83c52ef2-d0f4-41ac-bada-93e5350f67d1?1="1" HTTP/1.0\r\n 
Connection: Keep-Alive\r\n 
Host: 10.194.5.162:80\r\n 
Pragma: no-cache\r\n 
User-Agent: RealPlayer G2\r\n 
Expires: Mon, 18 May 1974 00:00:00 GMT\r\n 
Accept: application/x-rtsp-tunnelled, */*\r\n 
ClientID: WinNT_5.1_6.0.14.806_RealPlayer_R41UKD_en-GB_686\r\n 
X-Actual-URL: rtsp://10.194.5.162:554/01.mp3\r\n 
\r\n

這裏是服務器的響應：

HTTP/1.0 200 OK\r\n 
Server: RMServer 1.0\r\n 
Expires: Mon, 18 May 1974 00:00:00 GMT\r\n 
Pragma: no-cache\r\n 
x-server-ipaddress: 10.194.5.162\r\n 
Content-type: audio/x-pn-realaudio\r\n 
\r\n

此時4個字節，從到達服務器（它們的值是48 02 02 00） - 就是這樣，沒有更多。服務器是否期望客戶端的任何內容，如果是的話 - 是什麼？這種操作模式是否可以工作？

對這個問題的一些詳細信息：顯然，與RTSP通過HTTP內置的RealPlayer工作的打算機制如下：

嘗試連接到以下端口：80，8080，554，7070 。（也嘗試直接下載文件，只爲它赫克，通過發出GET端口80 http://hostname:port/mediafilename）
對於上述每個端口，創建2個連接。
發送GET請求到其中一個到url的連接http://hostname:port/SmpDsBhgRl<guid>？1 =「1」，其中<guid>是，是，新創建的GUID。爲此請求添加一個名爲X-Actual-URL的標題，其中包含原始RTSP URL。
在其他連接上發送POST請求，並將上面的GUID作爲請求主體的一部分加入到URL http://hostname:port/SmpDsBhgRl中。發送32767字節的內容長度標頭，以防止代理過早關閉連接。
開始通過POST請求向服務器發出命令，並獲取相應的RTSP流作爲GET響應的一部分。

奇怪的東西（如果上面不夠奇怪）是，例如，它適用於Squid，但不是如果您使用任何端口3128或8080！不知何故，客戶端使用它連接的端口來決定請求的順序或取消請求的時間，但無論如何，儘管難以置信，但它可以與代理端口9090,3129,8081一起使用，但是不與3128或8080.

更新＃2：Here是RealPlayer的來源，並解釋了上述行爲。但仍然沒有解決方案。

更新＃3：好的，鑑於上述情況，48 02 02 00的魔法值是清楚的：48 =='h'是HTTP_RESPONSE，接下來的02是以下數據的長度，接下來的02被稱爲POST_NOT_RECEIVED（意思是POST請求沒有在相應的GET請求的一秒鐘內到達服務器）。

更新＃4：此行爲（即具有巨大內容長度的POST請求）也是WebEx使用的ActiveX的特徵（可能還有許多其他Web應用程序需要到服務器的開放通道）。

來源

2008-11-03 user29402

服務器的HTTP 200 OK響應是否有效？我的服務器用於響應您的情況，但RealPlayer在打開GET和POST連接後停止響應。然後，我添加到響應48 02 00 00和Content-Length：4屬性的主體，它的工作原理...也許你需要修改你的HTTP OK響應並在收到POST連接後發送它，而不是在此之前。 – Cipi 2010-03-10 13:16:46

查看是否發出同樣的請求，但繞過代理（例如，重放你貼以上使用Netcat的請求）在響應身體流大於四個字節的結果。
看看的TCP報文的代理接收，例如，通過竊聽在TCP 交通是正在運行的代理，比如，使用Wireshark的機器上。

來源

2008-11-03 22:41:45 Alexander

首先，你可能需要閱讀此：

http://developer.apple.com/quicktime/icefloe/dispatch028.html

二，HTTP請求（GET和POST）需要進行格式化，使他們得到適當的代理。我見過堅持緩存POST請求的代理，防止它到達服務器。這些代理是錯誤的，但對此你無能爲力，而且我無法解決這個問題。大多數情況下，我都看到過這種反病毒軟件，它試圖對來自瀏覽器的POST請求進行透明代理，以掃描他們的私人信息，如社會安全號碼。您可能會遇到同樣的問題。

您是否使用McAfee的反病毒任何機會？

此外，似乎Real發明了自己的方式來做同樣的事情，但基本設計非常相似 - GET用於下游鏈接，POST用於上游，帶有一些魔術餅乾（在這種情況下，GUID ）將兩者聯繫在一起。無論哪種方式，POST應該到達服務器，在你的情況下，它似乎沒有。

順便說一句，因爲這個問題似乎是通過代理不會POST請求，如何發佈這一要求，除了得到什麼？

來源

2008-11-05 17:11:42

rtsp通過代理上的http

回答

相關問題