HTTP GET พร้อมเนื้อหาคำขอ

ฉันกำลังพัฒนา webservice RESTful ใหม่สำหรับแอปพลิเคชันของเรา

เมื่อทำการ GET กับบางเอนทิตีลูกค้าสามารถร้องขอเนื้อหาของเอนทิตี หากพวกเขาต้องการเพิ่มพารามิเตอร์บางอย่าง (ตัวอย่างเช่นการเรียงลำดับรายการ) พวกเขาสามารถเพิ่มพารามิเตอร์เหล่านี้ในสตริงแบบสอบถาม

อีกทางหนึ่งฉันต้องการให้ผู้คนสามารถระบุพารามิเตอร์เหล่านี้ในเนื้อหาคำขอ HTTP / 1.1ดูเหมือนจะไม่ได้รับการอนุญาตนี้อย่างชัดเจน สิ่งนี้จะช่วยให้พวกเขาระบุข้อมูลเพิ่มเติมอาจทำให้ง่ายขึ้นในการระบุคำขอ XML ที่ซับซ้อน

คำถามของฉัน:

• นี่เป็นความคิดที่ดีหรือไม่?
• ไคลเอนต์ HTTP จะมีปัญหากับการใช้เนื้อความคำขอภายในคำขอ GET หรือไม่

http://tools.ietf.org/html/rfc2616

ความคิดเห็นรอยฟีลดิงเกี่ยวกับร่างกายรวมทั้งที่มีการร้องขอการ GET

ใช่. กล่าวอีกนัยหนึ่งข้อความคำขอ HTTP ใด ๆ ที่ได้รับอนุญาตให้มีเนื้อหาของข้อความและดังนั้นจึงต้องแยกข้อความที่มีในใจ อย่างไรก็ตามซีแมนทิกส์ของเซิร์ฟเวอร์สำหรับ GET นั้นถูก จำกัด เช่นนั้นหากเนื้อหานั้นไม่มีความหมายเชิงความหมายต่อการร้องขอ ข้อกำหนดในการวิเคราะห์คำแยกจากข้อกำหนดในวิธีอรรถศาสตร์

ใช่คุณสามารถส่งเนื้อหาที่มี GET และไม่มันไม่มีประโยชน์ที่จะทำเช่นนั้น

นี่เป็นส่วนหนึ่งของการออกแบบเลเยอร์ของ HTTP / 1.1 ที่จะชัดเจนอีกครั้งเมื่อข้อมูลจำเพาะถูกแบ่งพาร์ติชัน (กำลังดำเนินการอยู่)

.... รอย

ใช่คุณสามารถส่งคำขอเนื้อหาด้วย GET แต่ไม่ควรมีความหมายใด ๆ หากคุณให้ความหมายโดยการแยกวิเคราะห์บนเซิร์ฟเวอร์และเปลี่ยนการตอบกลับของคุณตามเนื้อหาคุณจะเพิกเฉยต่อคำแนะนำนี้ในข้อมูลจำเพาะ HTTP / 1.1 ส่วน 4.3 :

[... ] หากวิธีการร้องขอไม่ได้รวมซีแมนทิกส์ที่กำหนดไว้สำหรับเอนทิตีเนื้อหาจากนั้นเนื้อหาของข้อความSHOULDจะถูกละเว้นเมื่อจัดการคำขอ

และคำอธิบายของวิธีการ GET ในข้อมูลจำเพาะ HTTP / 1.1 ส่วน 9.3 :

วิธีการ GET หมายถึงการดึงข้อมูลใด ๆ ([... ]) ถูกระบุโดย Request-URI

ซึ่งระบุว่าร่างกายร้องขอไม่ได้เป็นส่วนหนึ่งของการระบุของทรัพยากรในการร้องขอ GET เพียง URI คำขอ

อัปเดต RFC2616 ที่อ้างอิงเป็น "ข้อมูลจำเพาะ HTTP / 1.1" ล้าสมัยแล้ว ในปี 2014 มันถูกแทนที่ด้วย RFCs 7230-7237 อ้างอิง "ข้อความเนื้อหาควรถูกละเว้นเมื่อจัดการคำขอ" ถูกลบไปแล้ว ตอนนี้เป็นเพียง "การร้องขอการกำหนดกรอบข้อความเป็นอิสระจากความหมายของวิธีแม้ว่าวิธีการจะไม่กำหนดการใช้งานใด ๆ สำหรับเนื้อหาข้อความ" การอ้างอิงที่ 2 "วิธีการ GET หมายถึงการดึงข้อมูลใด ๆ ... ถูกระบุโดย Request-URI" ถูกลบแล้ว - จากความคิดเห็น

ในขณะที่คุณสามารถทำเช่นนั้นตราบเท่าที่มันไม่ได้ถูก จำกัด โดยข้อกำหนดของ HTTP อย่างชัดเจนฉันขอแนะนำให้หลีกเลี่ยงเพียงเพราะผู้คนไม่คาดหวังสิ่งต่าง ๆ ที่จะทำงานในลักษณะนั้น มีหลายขั้นตอนในห่วงโซ่การร้องขอ HTTP และในขณะที่พวกเขา "ส่วนใหญ่" เป็นไปตามข้อกำหนด HTTP สิ่งเดียวที่คุณมั่นใจได้ก็คือพวกเขาจะทำงานเหมือนเว็บเบราว์เซอร์ที่ใช้แบบดั้งเดิม (ฉันกำลังคิดถึงสิ่งต่าง ๆ เช่นพร็อกซี่โปร่งใสตัวเร่งความเร็วชุดเครื่องมือ A / V ฯลฯ )

นี่คือวิญญาณที่อยู่เบื้องหลังหลักการความแข็งแกร่ง "จงมีอิสระในสิ่งที่คุณยอมรับและอนุรักษ์ในสิ่งที่คุณส่ง" คุณไม่ต้องการผลักขอบเขตของข้อกำหนดโดยไม่มีเหตุผลที่ดี

อย่างไรก็ตามถ้าคุณมีเหตุผลที่ดีไปทำมัน

คุณอาจประสบปัญหาหากคุณพยายามใช้ประโยชน์จากแคช ผู้รับมอบฉันทะจะไม่ดูในเนื้อหาของ GET เพื่อดูว่าพารามิเตอร์มีผลกระทบต่อการตอบสนองหรือไม่

ทั้งrestclientและREST console ไม่รองรับสิ่งนี้ แต่ curl ทำได้

จำเพาะ HTTPกล่าวว่าในส่วน 4.3

ต้องไม่รวมเนื้อหาของข้อความในคำขอหากข้อมูลจำเพาะของวิธีการร้องขอ (ส่วน 5.1.1) ไม่อนุญาตให้ส่งเนื้อหาขององค์กรในคำขอ

ส่วน 5.1.1เปลี่ยนเส้นทางเราไปยังส่วน 9.x สำหรับวิธีการต่างๆ ไม่มีบุคคลใดที่ห้ามรวมข้อความอย่างชัดเจน อย่างไรก็ตาม ...

ส่วนที่ 5.2กล่าวว่า

ทรัพยากรที่แน่นอนที่ระบุโดยคำขอทางอินเทอร์เน็ตนั้นพิจารณาจากการตรวจสอบทั้ง Request-URI และฟิลด์ส่วนหัวของโฮสต์

และมาตรา 9.3พูดว่า

วิธีการ GET หมายถึงการดึงข้อมูลใด ๆ (ในรูปแบบของนิติบุคคล) จะถูกระบุโดย Request-URI

ซึ่งร่วมกันแนะนำว่าเมื่อประมวลผลคำขอ GET เซิร์ฟเวอร์ไม่จำเป็นต้องตรวจสอบสิ่งอื่นใดที่ฟิลด์ Request-URI และโฮสต์

โดยสรุปข้อมูลจำเพาะ HTTP ไม่ได้ป้องกันคุณจากการส่งเนื้อหา - ข้อความด้วย GET แต่มีความกำกวมเพียงพอที่จะไม่ทำให้ฉันแปลกใจหากเซิร์ฟเวอร์ทั้งหมดไม่รองรับ

Elasticsearch ยอมรับคำขอของ GET พร้อมเนื้อหา มันก็ดูเหมือนว่านี่เป็นวิธีที่ต้องการ: คู่มือ Elasticsearch

บางไลบรารีไคลเอ็นต์ (เช่นไดร์เวอร์ Ruby) สามารถบันทึกคำสั่ง cry เพื่อ stdout ในโหมดการพัฒนาและใช้ไวยากรณ์นี้อย่างกว้างขวาง

สิ่งที่คุณพยายามจะทำให้สำเร็จนั้นได้ทำมาเป็นเวลานานด้วยวิธีการทั่วไปที่มากขึ้นและวิธีการที่ไม่ต้องพึ่งพาการใช้ payload กับ GET

คุณสามารถสร้างประเภทการค้นหาเฉพาะของคุณหรือถ้าคุณต้องการที่จะสงบมากขึ้นใช้อะไรเช่น OpenSearch และโพสต์คำขอไปยัง URI ที่เซิร์ฟเวอร์สั่งให้พูด / ค้นหา เซิร์ฟเวอร์สามารถสร้างผลลัพธ์การค้นหาหรือสร้าง URI สุดท้ายและเปลี่ยนเส้นทางโดยใช้ 303

สิ่งนี้มีข้อดีของการทำตามวิธี PRG แบบดั้งเดิมช่วยให้ตัวกลางแคชแคชผลลัพธ์เป็นต้น

ที่กล่าวว่า URIs ถูกเข้ารหัสอยู่แล้วสำหรับสิ่งที่ไม่ใช่ ASCII และดังนั้นจึงเป็น application / x-www-form-urlencoded และ multipart / form-data ฉันขอแนะนำให้ใช้สิ่งนี้แทนที่จะสร้างรูปแบบ json แบบกำหนดเองอีกรูปแบบหากคุณต้องการสนับสนุนสถานการณ์จำลอง

คุณสามารถส่ง GET โดยใช้ร่างกายหรือส่ง POST และเลิกนับถือศาสนาอื่น ๆ (มันไม่เลวร้ายเมื่อ 5 ปีที่แล้วมีสมาชิกศรัทธาเพียงคนเดียว - ความคิดเห็นของเขาเชื่อมโยงด้านบน)

ไม่ใช่การตัดสินใจที่ยอดเยี่ยม แต่การส่งเนื้อหาของ GET อาจป้องกันปัญหาสำหรับลูกค้าบางราย - และเซิร์ฟเวอร์บางตัว

การทำโพสต์อาจมีอุปสรรคกับกรอบการคืนค่าใหม่

Julian Reschke แนะนำข้างต้นโดยใช้ส่วนหัว HTTP ที่ไม่ได้มาตรฐานเช่น "SEARCH" ซึ่งอาจเป็นโซลูชันที่สง่างามยกเว้นว่ามีโอกาสน้อยที่จะได้รับการสนับสนุน

มันอาจจะเป็นผลดีที่สุดในการทำรายชื่อลูกค้าที่สามารถและไม่สามารถทำสิ่งต่าง ๆ ข้างต้น

ลูกค้าที่ไม่สามารถส่ง GET ด้วยเนื้อหา (ที่ฉันรู้):

• XmlHTTPRiddest Fiddler

ลูกค้าที่สามารถส่ง GET พร้อมเนื้อหา:

• เบราว์เซอร์ส่วนใหญ่

เซิร์ฟเวอร์และไลบรารีที่สามารถดึงเนื้อหาจาก GET:

• อาปาเช่
• PHP

เซิร์ฟเวอร์ (และพรอกซี) ที่ดึงเนื้อหาจาก GET:

• ?

ฉันนำคำถามนี้ไปใช้กับ IETF HTTP WG ความคิดเห็นจาก Roy Fielding (ผู้เขียนเอกสาร http / 1.1 ในปี 1998) นั้น

"... การนำไปปฏิบัติจะแตกหักหากทำสิ่งอื่นนอกเหนือจากการแยกวิเคราะห์และทิ้งร่างนั้นหากได้รับ"

รัฐ RFC 7213 (HTTPbis):

"เพย์โหลดภายในข้อความขอ GET ไม่มีความหมายที่กำหนดไว้"

ดูเหมือนชัดเจนในตอนนี้ว่าเจตนาคือความหมายเชิงความหมายในหน่วยงานคำขอ GET เป็นสิ่งต้องห้ามซึ่งหมายความว่าไม่สามารถใช้เนื้อความคำขอเพื่อส่งผลต่อผลลัพธ์

มีผู้รับมอบฉันทะออกมีที่จะมีความแน่นอนทำลายคำขอของคุณในรูปแบบต่างๆถ้าคุณรวมร่างกายบน GET

ดังนั้นโดยสรุปอย่าทำมัน

เซิร์ฟเวอร์ใดที่จะเพิกเฉย - fijiaaron 30 ส.ค. 2555 เวลา 21:27 น

ตัวอย่างเช่นGoogleกำลังทำสิ่งที่เลวร้ายยิ่งกว่าการเพิกเฉยมันจะพิจารณาว่าเป็นข้อผิดพลาด !

ลองด้วยตัวคุณเองด้วย netcat แบบง่าย ๆ :

$ netcat www.google.com 80
GET / HTTP/1.1
Host: www.google.com
Content-length: 6

1234

(เนื้อหา 1234 จะตามด้วย CR-LF ดังนั้นจะมีทั้งหมด 6 ไบต์)

และคุณจะได้รับ:

HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That’s an error.
Your client has issued a malformed or illegal request. That’s all we know.

คุณจะได้รับ 400 Bad Request จาก Bing, Apple และอื่น ๆ ... ซึ่ง AkamaiGhost ให้บริการ

ดังนั้นฉันจะไม่แนะนำให้ใช้คำขอ GET กับเอนทิตีร่างกาย

จากRFC 2616 ส่วน 4.3 "เนื้อหาของข้อความ":

เซิร์ฟเวอร์ควรอ่านและส่งต่อเนื้อความในการร้องขอใด ๆ ; หากวิธีการร้องขอไม่ได้รวมซีแมนทิกส์ที่กำหนดไว้สำหรับเอนทิตีเนื้อหาจากนั้นเนื้อหาของข้อความ SHOULD จะถูกละเว้นเมื่อจัดการคำขอ

นั่นคือเซิร์ฟเวอร์ควรอ่านเนื้อความคำขอใด ๆ ที่จัดไว้ให้จากเครือข่าย (ตรวจสอบความยาวเนื้อหาหรืออ่านเนื้อหาที่มีการสับเปลี่ยนเป็นต้น) นอกจากนี้ผู้รับมอบฉันทะควรส่งต่อสิ่งที่ร้องขอดังกล่าวที่ได้รับ จากนั้นหาก RFC กำหนดซีแมนทิกส์สำหรับเนื้อความสำหรับวิธีการที่กำหนดเซิร์ฟเวอร์สามารถใช้เนื้อความคำขอจริงในการสร้างการตอบสนอง อย่างไรก็ตามหาก RFC ไม่ได้กำหนดซีแมนทิกส์สำหรับเนื้อความเซิร์ฟเวอร์ควรละเว้น

นี่เป็นไปตามที่อ้างจากฟีลดิงข้างต้น

ส่วน 9.3 "GET" อธิบายถึงความหมายของวิธีการ GET และไม่ได้กล่าวถึงเนื้อหาที่ร้องขอ ดังนั้นเซิร์ฟเวอร์ควรเพิกเฉยต่อคำขอใด ๆ ที่ได้รับจากคำขอ GET

ตาม XMLHttpRequest มันไม่ถูกต้อง จากมาตรฐาน :

4.5.6 send()วิธีการ

client . send([body = null])

เริ่มต้นคำขอ อาร์กิวเมนต์ที่เป็นทางเลือกจัดเตรียมเนื้อความคำขอ อาร์กิวเมนต์จะถูกละเว้นถ้าวิธีการร้องขอหรือGETHEAD

ส่งInvalidStateErrorข้อยกเว้นหากสถานะใดสถานะหนึ่งไม่ถูก เปิดหรือsend()ตั้งค่าสถานะ

วิธีการต้องเรียกใช้ขั้นตอนเหล่านี้:send(body)

1. หากไม่ได้เปิดสถานะให้โยนInvalidStateErrorข้อยกเว้น
2. หากsend()มีการตั้งค่าสถานะโยนInvalidStateErrorข้อยกเว้น
3. หากวิธีการร้องขอเป็นGETหรือHEADตั้งค่าร่างกายเป็นโมฆะ
4. ถ้าร่างกายเป็นโมฆะไปที่ขั้นตอนถัดไป

แม้ว่าฉันไม่คิดว่ามันควรจะเพราะคำขอ GET อาจต้องการเนื้อหาที่มีขนาดใหญ่

ดังนั้นหากคุณพึ่งพา XMLHttpRequest ของเบราว์เซอร์เป็นไปได้ว่ามันจะไม่ทำงาน

ถ้าคุณอยากที่จะส่ง JSON ร่างกาย / XML cachable ไปยังโปรแกรมประยุกต์เว็บสถานที่เดียวที่เหมาะสมที่จะนำข้อมูลของคุณสตริงแบบสอบถามเข้ารหัสด้วยRFC4648: ฐาน 64 เข้ารหัสด้วย URL และชื่อไฟล์เซฟตัวอักษร แน่นอนคุณสามารถ urlencode JSON และใส่เป็นค่าของ URL พารามิเตอร์ แต่ Base64 ให้ผลลัพธ์ที่มีขนาดเล็กลง โปรดทราบว่ามีข้อ จำกัด ขนาด URL โปรดดูความยาวสูงสุดของ URL ในเบราว์เซอร์ที่ต่างกันคือเท่าใด .

คุณอาจคิดว่า padding Base64 ของ=ตัวละครอาจจะไม่ดีสำหรับค่าพารามิเตอร์ของ URL แต่ดูเหมือนไม่ได้ - ดูการอภิปรายนี้: http://mail.python.org/pipermail/python-bugs-list/2007-February/037195.html อย่างไรก็ตามคุณไม่ควรใส่ข้อมูลที่เข้ารหัสโดยไม่มีชื่อพารามิเตอร์เนื่องจากสตริงที่เข้ารหัสด้วยการขยายจะถูกตีความว่าเป็นคีย์พารามิเตอร์ที่มีค่าว่าง ?_b64=<encodeddata>ฉันจะใช้สิ่งที่ต้องการ

ฉันจะไม่แนะนำสิ่งนี้มันขัดกับหลักปฏิบัติทั่วไปและไม่ได้ให้ผลตอบแทนมากนัก คุณต้องการให้เนื้อหาเป็นเนื้อหาไม่ใช่ตัวเลือก

ส่วนหัวที่เข้ารหัสไม่เป็นไปตาม base64 หรือไม่ "SOMETHINGAPP-params: sdfSD45fdg45 / AS"

ข้อจำกัดความยาว hm คุณไม่สามารถทำการจัดการ POST แยกแยะระหว่างความหมายได้หรือไม่? หากคุณต้องการพารามิเตอร์อย่างง่ายเช่นการเรียงลำดับฉันไม่เห็นสาเหตุที่เป็นปัญหา ฉันเดาว่าแน่นอนว่าคุณเป็นห่วง

ฉันเสียใจที่ REST เนื่องจากโปรโตคอลไม่รองรับ OOP และGetวิธีนี้เป็นข้อพิสูจน์ ในฐานะที่เป็นวิธีแก้ปัญหาคุณสามารถทำให้อนุกรม DTO ของคุณเป็น JSON จากนั้นสร้างสตริงการสืบค้น ในฝั่งเซิร์ฟเวอร์คุณจะสามารถทำการดีซีเรียลไลซ์สตริงการสืบค้นให้กับ DTO ได้

ดูที่:

• การออกแบบข้อความใน ServiceStack
• การสร้าง RESTful Message Based Web Services ด้วย WCF

วิธีการตามข้อความสามารถช่วยให้คุณแก้ปัญหารับข้อ จำกัด ของวิธีการ คุณจะสามารถส่ง DTO ใด ๆ ก็ได้ตามที่ร้องขอ

เฟรมเวิร์กบริการเว็บ Nelibur มีฟังก์ชันการทำงานที่คุณสามารถใช้ได้

var client = new JsonServiceClient(Settings.Default.ServiceAddress);
var request = new GetClientRequest
    {
        Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573")
    };
var response = client.Get<GetClientRequest, ClientResponse>(request);

as you can see, the GetClientRequest was encoded to the following query string

http://localhost/clients/GetWithResponse?type=GetClientRequest&data=%7B%22Id%22:%2217239b0e-b35b-4d32-95c7-5db43e2bd573%22%7D

ตัวอย่างเช่นทำงานกับ Curl, Apache และ PHP

ไฟล์ PHP:

<?php
echo $_SERVER['REQUEST_METHOD'] . PHP_EOL;
echo file_get_contents('php://input') . PHP_EOL;

คำสั่งคอนโซล:

$ curl -X GET -H "Content-Type: application/json" -d '{"the": "body"}' 'http://localhost/test/get.php'

เอาท์พุท:

GET
{"the": "body"}

IMHO คุณสามารถส่งการJSONเข้ารหัส (เช่นencodeURIComponent) ในURLวิธีนี้คุณจะไม่ละเมิดHTTPรายละเอียดและนำคุณJSONไปยังเซิร์ฟเวอร์

คุณมีรายการตัวเลือกที่ดีกว่าการใช้เนื้อหาคำขอกับ GET

สมมติว่าคุณมีหมวดหมู่และรายการสำหรับแต่ละหมวดหมู่ ทั้งสองจะถูกระบุโดย id ("catid" / "itemid" เพื่อเป็นตัวอย่างนี้) คุณต้องการจัดเรียงตามพารามิเตอร์อื่น "sortby" ใน "order" ที่เฉพาะเจาะจง คุณต้องการส่งพารามิเตอร์สำหรับ "sortby" และ "order":

คุณสามารถ:

1. ใช้สตริงแบบสอบถามเช่น example.com/category/{catid}/item/{itemid}?sortby=itemname&order=asc
2. ใช้ mod_rewrite (หรือคล้ายกัน) สำหรับเส้นทาง: example.com/category/{catid}/item/{itemid}/{sortby}/{order}
3. ใช้ส่วนหัว HTTP แต่ละรายการที่คุณผ่านพร้อมคำขอ
4. ใช้วิธีอื่นเช่น POST เพื่อดึงทรัพยากร

ทุกคนมีข้อเสีย แต่ก็ยังดีกว่าการใช้ GET กับร่างกาย

แม้ว่าเครื่องมือยอดนิยมจะใช้สิ่งนี้ตามที่อ้างถึงบ่อยครั้งในหน้านี้ฉันคิดว่ามันยังเป็นความคิดที่ไม่ดีอยู่ดีเกินไปแม้ว่าจะไม่ได้รับอนุญาตจากสเป็ค

โครงสร้างพื้นฐานระดับกลางหลายแห่งอาจปฏิเสธคำขอดังกล่าว

โดยตัวอย่างลืมเกี่ยวกับการใช้บางส่วนของ CDN ที่มีอยู่ในด้านหน้าของเว็บไซต์ของคุณเช่นนี้หนึ่ง :

หากGETคำขอของผู้ดูมีเนื้อหา BodyFront จะส่งคืนรหัสสถานะ HTTP 403 (ต้องห้าม) ให้กับผู้ดู

และใช่ห้องสมุดลูกค้าของคุณอาจไม่สนับสนุนการส่งคำขอดังกล่าวตามที่รายงานไว้ในความคิดเห็นนี้

ฉันใช้ RestTemplate ของ Spring framework ในโปรแกรมไคลเอนต์ของฉันและที่ฝั่งเซิร์ฟเวอร์ฉันได้กำหนดคำขอ GET ด้วยเนื้อความ Json จุดประสงค์หลักของฉันก็เหมือนกับของคุณ: เมื่อคำขอมีพารามิเตอร์จำนวนมากการใส่ไว้ในร่างกายดูเหมือนจะเป็นระเบียบเรียบร้อยกว่าการใส่ไว้ในสตริง URI ที่ยืดเยื้อ ใช่?

แต่น่าเศร้าที่มันไม่ทำงาน! ฝั่งเซิร์ฟเวอร์ส่งข้อยกเว้นต่อไปนี้:

org.springframework.http.converter.HttpMessageNotReadableException: เนื้อหาคำขอที่ต้องการหายไป ...

แต่ฉันค่อนข้างแน่ใจว่าเนื้อหาของข้อความนั้นถูกต้องโดยรหัสลูกค้าของฉันดังนั้นเกิดอะไรขึ้น

ฉันติดตามไปยังเมธอด RestTemplate.exchange () และพบสิ่งต่อไปนี้:

// SimpleClientHttpRequestFactory.class
public class SimpleClientHttpRequestFactory implements ClientHttpRequestFactory, AsyncClientHttpRequestFactory {
    ...
    protected void prepareConnection(HttpURLConnection connection, String httpMethod) throws IOException {
        ...
        if (!"POST".equals(httpMethod) && !"PUT".equals(httpMethod) && !"PATCH".equals(httpMethod) && !"DELETE".equals(httpMethod)) {
            connection.setDoOutput(false);
        } else {
            connection.setDoOutput(true);
        }
        ...
    }
}

// SimpleBufferingClientHttpRequest.class
final class SimpleBufferingClientHttpRequest extends AbstractBufferingClientHttpRequest {
    ...
    protected ClientHttpResponse executeInternal(HttpHeaders headers, byte[] bufferedOutput) throws IOException {
        ...
        if (this.connection.getDoOutput() && this.outputStreaming) {
            this.connection.setFixedLengthStreamingMode(bufferedOutput.length);
        }

        this.connection.connect();
        if (this.connection.getDoOutput()) {
            FileCopyUtils.copy(bufferedOutput, this.connection.getOutputStream());
        } else {
            this.connection.getResponseCode();
        }
        ...
    }
}

โปรดสังเกตว่าในเมธอด executeInternal () อาร์กิวเมนต์อินพุต 'bufferedOutput' มีเนื้อหาข้อความที่ระบุโดยรหัสของฉัน ฉันเห็นมันผ่านตัวดีบั๊ก

อย่างไรก็ตามเนื่องจากการเตรียมความพร้อมการเชื่อมต่อ (), getDoOutput () ใน executeInternal () มักจะส่งกลับเท็จซึ่งในทางกลับกันทำให้ bufferedOutput ถูกเพิกเฉยอย่างสมบูรณ์! มันไม่ได้คัดลอกไปยังสตรีมเอาต์พุต

ดังนั้นโปรแกรมเซิร์ฟเวอร์ของฉันไม่ได้รับเนื้อหาข้อความและส่งข้อยกเว้นนั้น

นี่คือตัวอย่างเกี่ยวกับ RestTemplate ของ Spring framework ประเด็นก็คือแม้ว่าเนื้อหาข้อความจะไม่ได้รับอนุญาตจากข้อกำหนด HTTP อีกต่อไปไคลเอนต์หรือเซิร์ฟเวอร์ไลบรารีหรือกรอบงานบางอย่างอาจยังคงสอดคล้องกับข้อมูลจำเพาะเก่าและปฏิเสธเนื้อหาข้อความจากคำขอ GET