एक इकाई निकाय अनुरोध के लिए एक इकाई निकाय की अनुमति है?

Question

HTTP डिलीट अनुरोध जारी करते समय, अनुरोध यूआरआई को पूरी तरह से हटाने के लिए संसाधन की पहचान करनी चाहिए। हालांकि, क्या अनुरोध के इकाई निकाय के हिस्से के रूप में अतिरिक्त मेटा-डेटा जोड़ने की अनुमति है?

Answer 1

The spec स्पष्ट रूप से इसे प्रतिबंधित या हतोत्साहित नहीं करता है, इसलिए मैं कहूंगा कि इसकी अनुमति है।

माइक्रोसॉफ्ट ने इसे उसी तरह देखता है (मैं दर्शकों में बड़बड़ा सुन सकते हैं), वे के बारे में DELETE Method of ADO.NET Data Services Framework MSDN लेख में राज्य:

एक हटाने का अनुरोध एक इकाई शरीर शामिल है, तो शरीर को नजरअंदाज कर दिया जाता है [ ...]

साथ ही यहाँ है क्या RFC2616 (HTTP 1.1) अनुरोध के संबंध में क्या कहना है:

• एक इकाई शरीर ही मौजूद है जब एक संदेश-शरीर मौजूद है (खंड 7.2)
• एक संदेश-शरीर की उपस्थिति एक Content-Length या Transfer-Encoding हैडर के शामिल किए जाने से संकेत है (धारा 4.3)
• एक संदेश-शरीर शामिल नहीं किया जाना चाहिए जब अनुरोध विधि के विनिर्देश एक इकाई शरीर (धारा 4.3)
• भेजने में इकाई शरीर स्पष्ट ट्रेस reques में मना रहा है की अनुमति नहीं है ts केवल, अन्य सभी अनुरोध प्रकार के कोई रोक नहीं हैं (धारा 9, और 9.8 विशेष रूप से)

प्रतिक्रियाओं के लिए, यह परिभाषित किया गया है:

• है कि क्या एक संदेश-शरीर शामिल किया गया है दोनों अनुरोध पर निर्भर करता है विधि और प्रतिसाद स्थिति (धारा 4.3)
• एक संदेश-शरीर स्पष्ट HEAD अनुरोध करने के लिए प्रतिक्रिया में मना किया है (धारा 9, और 9.4 विशेष रूप से)
• संदेश-शरीर स्पष्ट रूप से 1xx (सूचनात्मक), 204 (कोई सामग्री नहीं), और 304 (संशोधित नहीं) प्रतिक्रियाओं (धारा 4.3)
• अन्य सभी प्रतिक्रियाओं में एक संदेश-शरीर शामिल है, हालांकि यह हो सकता है शून्य लंबाई (सेक्शन 4.3)

Answer 2

ऐसा लगता है कि RFC 2616 यह निर्दिष्ट नहीं करता है।

धारा 4.3 से

:

एक अनुरोध में संदेश-शरीर की उपस्थिति अनुरोध का संदेश-हेडर में एक सामग्री-लंबाई या स्थानांतरण-एन्कोडिंग हेडर फ़ील्ड की शामिल किए जाने के संकेत देते है। अनुरोध विधि (खंड 5.1.1) अनुरोध के विनिर्देशन को अनुरोध करने की अनुमति नहीं देता है, तो संदेश संदेश को में एक अनुरोध में शामिल नहीं किया जाना चाहिए।एक सर्वर को किसी भी अनुरोध पर संदेश-निकाय को पढ़ और अग्रेषित करना चाहिए; यदि अनुरोध विधि में इकाई-निकाय के लिए परिभाषित अर्थशास्त्र शामिल नहीं है, तो अनुरोध को संभालने के दौरान संदेश-निकाय को अनदेखा किया जाना चाहिए।

और अनुभाग 9.7:

हटाएँ विधि अनुरोध करता है कि मूल सर्वर संसाधन अनुरोध- URI द्वारा की पहचान को हटा दें। इस विधि को मूल सर्वर पर मानव हस्तक्षेप (या अन्य साधन) द्वारा ओवरराइड किया जा सकता है। क्लाइंट की गारंटी नहीं दे सकता है कि ऑपरेशन किया गया है, भले ही मूल सर्वर से लौटाया गया स्टेटस कोड इंगित करता है कि कार्रवाई सफलतापूर्वक पूर्ण हो गई है। हालांकि, सर्वर को सफलता का संकेत नहीं देना चाहिए, जब तक प्रतिक्रिया दी जाती है, तो संसाधन को हटाने या इसे एक अप्राप्य स्थान पर ले जाने का इरादा रखता है।

एक सफल प्रतिक्रिया हो जाना चाहिए 200 (ठीक) यदि प्रतिक्रिया अभी तक अधिनियमित यदि कार्रवाई नहीं की गई है, या 204 (कोई सामग्री) यदि कार्रवाई अधिनियमित किया गया है स्थिति, 202 (स्वीकृत) का वर्णन एक इकाई भी शामिल है लेकिन प्रतिक्रिया में एक इकाई शामिल नहीं है।

अनुरोध एक कैश से होकर गुजरता है और अनुरोध- URI को पहचानती है एक या अधिक वर्तमान में कैश की गई संस्थाओं हैं, तो यह इन प्रविष्टियों को बासी के रूप में व्यवहार किया जाना चाहिए। इस विधि को जवाब cacheable.c नहीं कर रहे हैं

तो यह स्पष्ट रूप से अनुमति या अस्वीकृत नहीं कर रहा है, और इस बात की संभावना है कि रास्ते में एक प्रॉक्सी संदेश के मुख्य भाग को निकाल सकते हैं (हालांकि यह पढ़ सकते हैं और इसे आगे जाना चाहिए) है।

Answer 3

टोमकैट और जेट्टी के कुछ संस्करण मौजूद होने पर एक इकाई निकाय को अनदेखा करते हैं। यदि आप इसे प्राप्त करना चाहते हैं तो कौन सा उपद्रव हो सकता है।

Answer 4

HTTP 1.1 विनिर्देश (RFC 7231) के लिए नवीनतम अद्यतन स्पष्ट रूप से एक हटाने का अनुरोध में एक इकाई शरीर परमिट:

एक हटाने का अनुरोध संदेश के भीतर एक पेलोड कोई परिभाषित अर्थ विज्ञान है; DELETE अनुरोध पर एक पेलोड बॉडी भेजना कुछ मौजूदा कार्यान्वयन अनुरोध को अस्वीकार कर सकता है। https://www.elastic.co/guide/en/elasticsearch/reference/5.x/search-request-scroll.html#_clear_scroll_api

Netty इस समर्थन जिसका मतलब है:

Answer 5

यह ElasticSearch लगता है इस का उपयोग करता है।

जैसा टिप्पणी में mentionned यह मामला नहीं हो सकता है अब और

Answer 6

एक एक नष्ट अनुरोध में शरीर का उपयोग करने के आशावादी संगामिति नियंत्रण के लिए है कारण।

आपने रिकॉर्ड के संस्करण 1 को पढ़ा है।

GET /some-resource/1 
200 OK { id:1, status:"unimportant", version:1 } 

आपका सहयोगी रिकॉर्ड के संस्करण 1 पढ़ता है।

GET /some-resource/1 
200 OK { id:1, status:"unimportant", version:1 } 

आपका सहयोगी रिकॉर्ड बदलता है और डेटाबेस है, जो करने के लिए 2 संस्करण अद्यतन करता है अद्यतन करता है:

DELETE /some-resource/1 { id:1, version:1 } 
409 Conflict 

आप एक आशावादी मिलना चाहिए:

PUT /some-resource/1 { id:1, status:"important", version:1 } 
200 OK { id:1, status:"important", version:2 } 

आप रिकार्ड को हटाने का प्रयास ताला अपवाद। रिकॉर्ड दोबारा पढ़ें, देखें कि यह महत्वपूर्ण है, और शायद इसे हटा नहीं सकता है। (उदाहरण के लिए, रो-चयन के साथ एक ग्रिड चेक-बक्से)

इसका इस्तेमाल करने की एक और कारण एक समय में एकाधिक रिकॉर्ड नष्ट करने के लिए है।

DELETE /messages 
[{id:1, version:2}, 
{id:99, version:3}] 
204 No Content 

ध्यान दें कि प्रत्येक संदेश का अपना संस्करण है। हो सकता है कि आप एकाधिक शीर्षकों का उपयोग करके एकाधिक संस्करण निर्दिष्ट कर सकें, लेकिन जॉर्ज द्वारा, यह आसान और अधिक सुविधाजनक है।

यह, बिलाव (7.0.52) और स्प्रिंग MVC (4.05) में काम करता है पूर्व संस्करणों भी w संभवतः:

@RestController 
public class TestController { 

    @RequestMapping(value="/echo-delete", method = RequestMethod.DELETE) 
    SomeBean echoDelete(@RequestBody SomeBean someBean) { 
     return someBean; 
    } 
} 

Answer 7

मामले में किसी को भी इस मुद्दे के परीक्षण में चल रहा है, कोई उसे वैश्विक रूप से समर्थित नहीं है।

मैं वर्तमान में साहि प्रो के साथ परीक्षण कर रहा हूं और यह बहुत स्पष्ट है कि http DELETE कॉल स्ट्रिप किसी भी प्रदत्त बॉडी डेटा (आईडी की एक बड़ी सूची एंडपॉइंट डिज़ाइन के अनुसार थोक में हटाने के लिए) है।

मैं उनके साथ कई बार के रूप में शेयरों, चित्र, लॉग के तीन अलग-अलग पैकेज में भेजा उनकी समीक्षा करने के लिए और वे अभी भी इस बात की पुष्टि नहीं की है संपर्क में रहे हैं और साथ ही। एक असफल पैच, और बाद में उनके समर्थन से एक मिस्ड कॉन्फ्रेंस कॉल और मुझे अभी भी ठोस जवाब नहीं मिला है।

मैं कुछ साही इस का समर्थन नहीं करता हूँ, और मैं कई अन्य उपकरण सूट का पालन कल्पना कर सकते हैं।

Answer 8

बस एक सिर ऊपर, अगर आप अपने हटाने का अनुरोध में एक शरीर की आपूर्ति और Google क्लाउड HTTPS लोड संतुलन का उपयोग कर रहे हैं, यह एक 400 त्रुटि के साथ अपने अनुरोध को अस्वीकार कर देंगे। मैं एक दीवार के खिलाफ अपने सिर पर टक्कर लगी थी और यह पता चला कि Google, किसी भी कारण से, सोचता है कि शरीर के साथ एक अनुरोध अनुरोध एक विकृत अनुरोध है।

Answer 9

यह परिभाषित नहीं है।

एक DELETE अनुरोध संदेश के भीतर एक पेलोड कोई परिभाषित अर्थशास्त्र नहीं है; एक DELETE अनुरोध पर एक पेलोड बॉडी भेजकर अनुरोध को अस्वीकार करने के लिए कुछ मौजूदा कार्यान्वयन हो सकता है।
https://tools.ietf.org/html/rfc7231#page-29