प्रॉक्सी पर http पर आरटीएसपी

Question

मैं प्रॉक्सी का उपयोग कर HTTP पर एक आरटीएसपी धारा लाने की कोशिश कर रहा हूं। असली ग्राहक का व्यवहार थोड़ा व्यस्त लगता है: यह एक ही समय में सभी संभावित बंदरगाहों, विधियों और प्रोटोकॉल की कोशिश करता है। एकमात्र चीज जो काम करना चाहिए वह HTTP 80 से अधिक है। ऐसा अनुरोध वास्तव में जारी किया जाता है, और सर्वर पर प्राप्त होता है।

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) - और यह है, और कुछ नहीं। क्या सर्वर इस बिंदु पर ग्राहक से कुछ भी उम्मीद करता है, और यदि ऐसा है - क्या? क्या ऑपरेशन का यह तरीका बिल्कुल काम करता है?

इस समस्या पर कुछ अधिक जानकारी: इस प्रकार जाहिरा तौर पर, HTTP वी.ओ. में बनाया से अधिक RTSP साथ काम करने का इरादा तंत्र है: 80, 8080, 554, 7070: निम्नलिखित बंदरगाहों से कनेक्ट करने के

1. कोशिश (पोर्ट 80 पर जीईटी http://hostname:port/mediafilename जारी करके, इसे सीधे फ़ाइल डाउनलोड करने का प्रयास करें)
2. उपरोक्त बंदरगाहों में से प्रत्येक के लिए, 2 कनेक्शन बनाएं।
3. यूआरएल http://hostname:port/SmpDsBhgRl<guid> से कनेक्शन में से एक को एक अनुरोध भेजें? 1 = "1", जहां <guid> है, हां, एक ताजा बनाया गया GUID है। एक्स-एक्टुअल-यूआरएल नामक इस अनुरोध में एक शीर्षलेख जोड़ें जिसमें मूल आरटीएसपी यूआरएल है।
4. अनुरोध के निकाय के हिस्से के रूप में ऊपर GUID के साथ URL http://hostname:port/SmpDsBhgRl पर अन्य कनेक्शन पर एक POST अनुरोध भेजें। प्रॉक्सी को समय-समय पर कनेक्शन बंद करने से रोकने के लिए, 32767 बाइट्स का एक सामग्री-लंबाई शीर्षलेख भेजें।
5. POST अनुरोध के माध्यम से सर्वर को आदेश जारी करना प्रारंभ करें, और जीईटी प्रतिक्रिया के हिस्से के रूप में संबंधित आरटीएसपी धारा प्राप्त करें।

अजीब सामान (यदि ऊपर काफी अजीब नहीं है) कि, उदाहरण के लिए, यह विद्रूप के साथ काम करता है, लेकिन अगर आप बंदरगाहों 3128 या 8080 में से किसी का उपयोग नहीं! किसी भी तरह, ग्राहक अनुरोध के आदेश पर निर्णय लेने के लिए कनेक्ट होने वाले बंदरगाह का उपयोग करता है या जब अनुरोध रद्द किया जाना चाहिए, लेकिन वैसे भी, जैसा विश्वास करना मुश्किल है, यह प्रॉक्सी पोर्ट 90 9 0, 3129, 8081 के साथ काम करता है, लेकिन 3128 या 8080 के साथ नहीं।

अद्यतन # 2: Here उपरोक्त व्यवहार की व्याख्या के साथ रीयलप्लेयर का स्रोत है। हालांकि अभी भी कोई समाधान नहीं है।

अद्यतन # 3: ठीक है, उपर्युक्त के प्रकाश में, 48 02 02 00 का जादू मूल्य स्पष्ट है: 48 == 'एच' HTTP_RESPONSE के लिए है, अगला 02 निम्न डेटा की लंबाई है, अगले 02 को POST_NOT_RECEIVED कहा जाता है (जिसका अर्थ है कि POST अनुरोध संबंधित जीईटी अनुरोध से दूसरे के भीतर सर्वर तक नहीं पहुंच पाया)।

अद्यतन # 4: यह व्यवहार (यानी विशाल सामग्री-लंबाई के साथ POST अनुरोध) WebEx (और संभवतः, कई अन्य वेब ऐप्स जिन्हें सर्वर के लिए एक खुले चैनल की आवश्यकता है) द्वारा उपयोग किए जाने वाले ActiveX की विशेषता है।

Answer 1

1. देखें कि क्या एक ही अनुरोध जारी करना है लेकिन प्रॉक्सी को छोड़ना (उदाहरण के लिए, नेटकैट का उपयोग करके ऊपर दिए गए अनुरोध को फिर से चलाएं) परिणामस्वरूप प्रतिक्रिया शरीर में चार से अधिक बाइट्स में परिणाम होता है।
2. देखें कि प्रॉक्सी क्या टीसीपी पैकेट प्राप्त कर रहा है, उदाहरण के लिए, टीसीपी पर प्रॉक्सी चलाने वाली मशीन पर यातायात द्वारा, वायरसहार्क का उपयोग करके, कहें।

Answer 2

सबसे पहले, आप इस पढ़ने के लिए चाहते हो सकता है:

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

दूसरा, HTTP अनुरोध (दोनों प्राप्त और पोस्ट) इतना है कि वे ठीक से प्रॉक्सी हो प्रारूपित किया जा करने की जरूरत है। मैंने प्रॉक्सी देखी है जो पोस्ट अनुरोध के बहुत अधिक कैशिंग पर जोर देती है, इसे सर्वर तक पहुंचने से रोकती है। उन प्रॉक्सी छोटी हैं, लेकिन इसके बारे में आप कुछ भी नहीं कर सकते हैं, और मैं उस मुद्दे के आसपास काम करने में सक्षम नहीं था। अधिकांशतः मैंने इसे एंटी-वायरस सॉफ़्टवेयर के साथ देखा है जो ब्राउज़र से आने वाले POST अनुरोधों के पारदर्शी प्रॉक्सी को सामाजिक सुरक्षा संख्या जैसे निजी जानकारी के लिए स्कैन करने का प्रयास करता है। आप एक ही समस्या में चल रहे हो सकता है।

क्या आप किसी भी मौके से मैकएफी के एंटी वायरस का उपयोग कर रहे हैं?

इसके अलावा, ऐसा लगता है कि रियल ने एक ही काम करने का अपना तरीका खोजा है, लेकिन मूल डिजाइन बहुत समान है - डाउनस्ट्रीम लिंक के लिए प्राप्त करें, अपस्ट्रीम के लिए पोस्ट करें, कुछ जादू कुकी के साथ (इस मामले में, GUID) सर्वर पर दोनों को एक साथ बांधने के लिए। किसी भी तरह से, POST सर्वर पर जाना चाहिए, और आपके मामले में ऐसा लगता है जैसे यह नहीं करता है।

वैसे, चूंकि समस्या प्रॉक्सी के माध्यम से नहीं जा रही POST अनुरोध के साथ प्रतीत होती है, जीईटी के अतिरिक्त, उस अनुरोध को पोस्ट करने के बारे में कैसे?