क्लासिक "रीस्टफुल वेब सर्विसेज" पुस्तक (ओ रेली, आईएसबीएन 978-0-596-52926-0) में यह पृष्ठ 251 पर कहता है "कुछ फ़ायरवॉल HTTP पुट ब्लॉक और हटाएं लेकिन पोस्ट नहीं । "रीस्टफुल पुट और डिलीट और फ़ायरवॉल
क्या यह अभी भी सच है?
यदि यह सच है तो मुझे डिलीट के लिए विकल्प को ओवरलोडेड पोस्ट को अनुमति देना होगा।
HTTP पुट/डिलीट अवरुद्ध फ़ायरवॉल आम तौर पर इनकमिंग कनेक्शन (फ़ायरवॉल के पीछे सर्वरों) को अवरुद्ध कर रहे हैं। मान लें कि आपके पास अपने एप्लिकेशन की सुरक्षा करने वाले फ़ायरवॉल पर नियंत्रण है, आपको इसके बारे में चिंता करने की आवश्यकता नहीं है।
इसके अलावा, अगर वे नेटवर्क यातायात पर गहन निरीक्षण कर रहे हैं तो फ़ायरवॉल केवल पुट/डिलीट ब्लॉक कर सकते हैं। एन्क्रिप्शन फ़ायरवॉल को यूआरएल का विश्लेषण करने से रोक देगा, इसलिए यदि आप एचटीटीपीएस का उपयोग कर रहे हैं (आप एसएसएल के साथ अपने डेटा की रक्षा कर रहे हैं, है ना?) आपके वेब सेवा तक पहुंचने वाले क्लाइंट मानक चार HTTP क्रियाओं में से किसी एक का उपयोग करने में सक्षम होंगे।
हम HTTPS का उपयोग कर रहे हैं। (दुह - मुझे एहसास होना चाहिए था कि फायरवॉल हेडर भी नहीं देख सकते हैं।) धन्यवाद! –
उत्कृष्ट। एचटीटीपीएस को लागू करने के लिए मेरे लिए इस मुद्दे को हल किया गया। घर पर खेलने वाले लोगों के लिए, मेरा संतुलन सर्वर (पाउंड) चीजों की रिपोर्ट कर रहा था जैसे: '6 सितंबर 13:00:08 bal01 पाउंड: (बी 6515 बी 70) त्रुटि 1.2.3 से पढ़ी गई।4: कनेक्शन का समय समाप्त हो गया: 'मुझे आज तक कोई जानकारी नहीं थी कि ये फायरवॉल द्वारा अवरुद्ध अनुरोधों को हटा दिया गया था। विशेष रूप से, पीयूटी अनुरोध ठीक से आ रहे थे। –
कुछ 7 परत फ़ायरवॉल इस डिग्री के लिए यातायात का विश्लेषण कर सकते हैं। लेकिन मुझे यकीन नहीं है कि कितने स्थान उन्हें इस तरह कॉन्फ़िगर करेंगे। आप serverfault.com पर जाँच कर सकते हैं देखने के लिए कैसे लोकप्रिय इस तरह के एक config हो सकता है (आप भी हमेशा के लिए अपने आईटी कर्मचारियों के साथ जांच कर सकता है)
आप एक फ़ायरवॉल जो कुछ भी आप चाहते हैं (कम से कम सिद्धांत में) ताकि डॉन कॉन्फ़िगर कर सकते हैं अगर कुछ sys व्यवस्थापक HTTP PUT/DELETE को ब्लॉक करते हैं तो आश्चर्यचकित नहीं होंगे।
HTTP PUT/DELETE का खतरा कुछ गलत कॉन्फ़िगर किए गए सर्वर से संबंधित है: PUT दस्तावेज़ों को प्रतिस्थापित करता है (और DELETE उन्हें लक्षित करता है ;-) लक्ष्य सर्वर पर। इसलिए कुछ sys admins कहीं भी एक क्रैक खोले जाने पर PUT को अवरुद्ध करने का अधिकार तय करते हैं।
हम फायरवॉल "परत 7" में अभिनय और सिर्फ IP परत ;-)
मैं एक पोस्ट अधिक भार एक हटाने का अनुरोध का समर्थन करने के बारे में चिंता नहीं करता पर नहीं के बारे में बात कर रहे हैं।
HTML 4.0 और XHTML 1.0 केवल समर्थन प्राप्त करें और पोस्ट (के माध्यम से) अनुरोध तो यह सुरंग पुट/जो सर्वर द्वारा पढ़ा है और उचित रूप से dispathced है एक गुप्त फ़ॉर्म क्षेत्र के माध्यम से नष्ट करने के लिए सामान्य है। यह तकनीक ब्राउज़र पर संगतता को बरकरार रखती है और आपको किसी फ़ायरवॉल के मुद्दों को अनदेखा करने की अनुमति देती है।
रूबी ऑन रेल और .NET दोनों इस फैशन में रीस्टफुल अनुरोधों को संभालते हैं।
एक तरफ के रूप में, पोस्ट करें, पोस्ट करें & DELETE अनुरोध वर्तमान में XMLHttpRequest अनुरोध ऑब्जेक्ट के माध्यम से पूरी तरह से समर्थित हैं। एक्सएचटीएमएल 2.0 आधिकारिक तौर पर GET, POST, PUT & डिलीट का समर्थन करता है।
इसके अलावा एचटीएमएल 5 केवल फॉर्मों पर प्राप्त/पोस्ट करने की इजाजत देता है हालांकि उदाहरण के लिए एएसपी.नेट एमवीसी एक छिपी हुई एक्स-एचटीटीपी-विधि-ओवरराइड फॉर्म फ़ील्ड का उपयोग करता है (यदि आप निश्चित रूप से एक को चुनना चुनते हैं) सही एचटीपीपीट पर सर्वर मैपिंग प्राप्त करने के लिए या HttpDelete विधि –
समस्या यह बताने के लिए है कि अनुरोध अवरुद्ध किया जाएगा या नहीं, और उस स्थिति में सुरंग पोस्ट पर हटा दें: मैं वास्तव में उपयोगकर्ताओं के 0.02% [उद्धरण वांछित] के लिए आरईएसटी तोड़ने के लिए तैयार नहीं हूं (यह कितनी बार यह है हो जाता)। –