ฉันต้องการส่วนหัวชนิดเนื้อหาสำหรับคำขอ HTTP GET หรือไม่

154

เท่าที่ฉันเข้าใจมีสองสถานที่ที่จะตั้งประเภทเนื้อหา:

ลูกค้ากำหนดประเภทเนื้อหาสำหรับร่างกายที่เขาส่งไปยังเซิร์ฟเวอร์ (เช่นโพสต์)
เซิร์ฟเวอร์ตั้งค่าประเภทเนื้อหาสำหรับการตอบสนอง

นี่หมายความว่าฉันไม่จำเป็นต้องหรือไม่ควรกำหนดประเภทเนื้อหาสำหรับคำขอของฉันทั้งหมด (ฝั่งไคลเอ็นต์) และถ้าฉันสามารถหรือควรประเภทเนื้อหาที่จะ?

นอกจากนี้ฉันอ่านในโพสต์สองสามฉบับว่าประเภทเนื้อหาของลูกค้าระบุประเภทเนื้อหาที่ลูกค้าต้องการรับ ดังนั้นจุดที่ 1 ของฉันอาจไม่ถูกต้อง?

http get content-type

— Martin Flucka
แหล่งที่มา

112

ตามที่RFC 7231 ส่วน 3.1.5.5 :

ผู้ส่งที่สร้างข้อความที่มีเนื้อหาส่วนของข้อมูล SHOULD จะสร้างฟิลด์ส่วนหัวของประเภทเนื้อหาในข้อความนั้นยกเว้นว่าประเภทสื่อที่ต้องการของการเป็นตัวแทนล้อมรอบไม่เป็นที่รู้จักของผู้ส่ง หากไม่มีส่วนหัวของเนื้อหาประเภทเนื้อหาผู้รับอาจถือว่าประเภทสื่อของ "application / octet-stream" ( [RFC2046], ส่วน 4.5.1 ) หรือตรวจสอบข้อมูลเพื่อกำหนดประเภทของมัน

หมายความว่าContent-Typeควรตั้งค่าส่วนหัว HTTP สำหรับPUTและPOSTคำขอเท่านั้น

— epoc
แหล่งที่มา

5

@Epoc ข้อความที่ยกมามีความหมายโดยนัยที่ดีที่สุด มันไม่จริงบอกว่าข้อความได้โดยไม่ต้องนิติบุคคลร่างกายSHOULD NOTได้แก่ ประเภทเนื้อหา เรามีคำพูดที่ชัดเจนหรือไม่?

— Pacerier

1

@Pierier โปรดอย่าสรุปข้อสรุปหลักของคำตอบของคนอื่นแม้ว่าจะเป็นเท็จ ฉันยอมรับว่าคำตอบของ Epoc นั้นผิด - ไม่มีอะไรในหัวข้อที่เขายกมาสำรองคำตอบของเขาและมันสมควรที่จะถูกลดระดับลง แต่นั่นไม่ได้หมายความว่าคุณควรแก้ไขคำตอบเพื่อกำจัดหลักฐานหลักและเปลี่ยนความหมายโดยสิ้นเชิง

— Mark Amery

8

ฉันคิดว่าพวกคุณกำลังอ่านคำพูดของ @ Epoc ด้วยเช่นกัน แน่นอนว่าส่วนที่ยกมาไม่ได้หมายความว่าเขาพูดว่ามันหมายถึงอะไร แต่ฉันคิดว่าข้อสรุปนั้นถูกต้องในบริบทของคำถาม OPs OP กำลังมองหาความชัดเจนว่าเมื่อใดที่ควรรวมเนื้อหาประเภทและเมื่อไม่มี Epoc ให้ข้อมูลเกี่ยวกับวิธีการใช้ส่วนหัวและสรุปว่านักพัฒนาที่เหมาะสมจะ: คุณ "ควร" ใช้ "ประเภทเนื้อหาสำหรับคำขอที่มีเนื้อหาของ payload (ส่วนใหญ่ PUT และ POST) และคุณอาจ" ไม่ควรใช้ " มันอยู่ในสถานที่ที่มันไม่เป็นประโยชน์เช่น GET หรือ HEAD ฯลฯ

— JVMATL

1

โพสต์ข้อความของคุณ "มันหมายถึง.." - ยืด

— Adrian Bartholomew

64

รับการร้องขอไม่ควรมีประเภทเนื้อหาเพราะพวกเขาไม่มีนิติบุคคลร้องขอ (นั่นคือร่างกาย)

— Dmitry Negoda
แหล่งที่มา

31

@ มิทรีอ้างถึงมิฉะนั้นจะถือว่าเป็นข้อสันนิษฐานไม่ใช่ความจริง

— Pacerier

6

ในขณะที่ฉันยอมรับว่าข้อมูลจำเพาะไม่ได้บอกว่าคุณไม่สามารถมี Content-Type ใน GET แต่ดูเหมือนว่า. Net จะบังคับใช้ใน HttpClient ดูstackoverflow.com/questions/10679214/…

— Adam

37

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

พวกเขาเป็นตัวเลือกแม้ว่า

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1

— Matthew Wilson
แหล่งที่มา

27

คำตอบที่ยอมรับนั้นผิด ใบเสนอราคาถูกต้องการยืนยันว่า PUT และ POST จะต้องไม่ถูกต้อง ไม่มีข้อกำหนดที่ PUT หรือ POST มีเนื้อหาเพิ่มเติมจริง ๆ และมีข้อห้ามไม่ให้ GET มีเนื้อหาอยู่จริง

RFC พูดอย่างชัดเจนว่าพวกเขาหมายความว่าอย่างไรIFFด้านข้างของคุณ (ไคลเอนต์หรือเซิร์ฟเวอร์ต้นทาง) จะส่งเนื้อหาเพิ่มเติมนอกเหนือจากส่วนหัว HTTP มันควรระบุส่วนหัวประเภทเนื้อหา แต่โปรดทราบว่าอนุญาตให้ละเว้นประเภทเนื้อหาและยังคงมีเนื้อหา (พูดโดยใช้ส่วนหัวความยาวเนื้อหา)

— user4157069
แหล่งที่มา

0

คำตอบสั้น ๆ : เป็นไปได้มากที่คุณไม่ต้องการมีส่วนหัวประเภทเนื้อหาสำหรับคำขอ HTTP GET แต่รายละเอียดดูเหมือนจะไม่ตัดส่วนหัวประเภทเนื้อหาสำหรับ HTTP GET เช่นกัน

วัสดุที่รองรับ:

"ประเภทเนื้อหา" เป็นส่วนหนึ่งของข้อมูลเมตาที่แสดง (เช่นส่วนของข้อมูล) ยกมาจาก RFC 7231 ส่วน 3.1 :
3.1 การแทนข้อมูลเมตา

ฟิลด์ส่วนหัวการเป็นตัวแทนให้ข้อมูลเมตาเกี่ยวกับการเป็นตัวแทน เมื่อข้อความมีส่วนของ payload ฟิลด์ส่วนหัวการแทนจะอธิบายถึงวิธีการตีความข้อมูลการเป็นตัวแทนที่อยู่ในส่วนของ payload ...

ฟิลด์ส่วนหัวต่อไปนี้นำเสนอเมทาดาทาที่เป็นตัวแทน:
```
+-------------------+-----------------+
| Header Field Name | Defined in...   |
+-------------------+-----------------+
| Content-Type      | Section 3.1.1.5 |
| ...               | ...             |
```
ยกมาจากRFC 7231 ส่วน 3.1.1.5 (โดยวิธีคำตอบที่เลือกในปัจจุบันมีการพิมพ์ผิดในหมายเลขส่วน):

ฟิลด์ส่วนหัว "ประเภทเนื้อหา" ระบุประเภทสื่อของการเป็นตัวแทนที่เกี่ยวข้อง
ในกรณีดังกล่าวContent-Typeส่วนหัวไม่ได้เกี่ยวกับคำขอ HTTP GET จริงๆ (หรือคำขอ POST หรือ PUT สำหรับเรื่องนั้น) มันเป็นเรื่องของน้ำหนักบรรทุกที่อยู่ภายในสิ่งที่ร้องขอ Content-Typeดังนั้นถ้าจะไม่มีน้ำหนักบรรทุกที่มีความต้องการไม่มี ในทางปฏิบัติมีการนำไปปฏิบัติบางอย่างและทำให้สมมติฐานที่เข้าใจได้ง่าย อ้างจากความคิดเห็นของอดัม :

"ในขณะที่ ... ข้อมูลจำเพาะไม่ได้บอกว่าคุณไม่สามารถมี Content-Type บน GET แต่ดูเหมือนว่า. Net จะบังคับใช้ใน HttpClient ดูที่คำถามและคำตอบนี้"
อย่างไรก็ตามการพูดอย่างเคร่งครัดรายละเอียดตัวเองไม่ได้ออกกฎความเป็นไปได้ของ HTTP GET มีน้ำหนักบรรทุก ยกมาจากRFC 7231 ส่วน 4.3.1 :

4.3.1 ได้รับ

...

เพย์โหลดภายในข้อความขอ GET ไม่มีความหมายที่กำหนดไว้ การส่งส่วนของข้อมูลที่โหลดบนคำขอ GET อาจทำให้การใช้งานที่มีอยู่บางส่วนปฏิเสธคำขอ

ดังนั้นหาก HTTP GET ของคุณรวมเพย์โหลดไม่ว่าด้วยเหตุผลใดก็ตามContent-Typeส่วนหัวก็อาจสมเหตุสมผลเช่นกัน

— RayLuo
แหล่งที่มา

-2

ปัญหาของการไม่ส่งต่อชนิดเนื้อหาในข้อความ GET คือการตรวจสอบว่าประเภทเนื้อหานั้นไม่เกี่ยวข้องเนื่องจากฝั่งเซิร์ฟเวอร์กำหนดเนื้อหาอยู่แล้ว ปัญหาที่ฉันพบคือตอนนี้มีหลายแห่งที่ตั้งค่าเว็บเซอร์ของพวกเขาให้ฉลาดพอที่จะเลือกประเภทเนื้อหาที่คุณผ่านและตอบกลับใน 'ชนิด' ที่คุณร้องขอ เช่น. ขณะนี้เรากำลังส่งข้อความพร้อมกับสถานที่ที่กำหนดค่าเริ่มต้นให้กับ JSON อย่างไรก็ตามพวกเขาได้ตั้งค่าเว็บเซอร์วิซเพื่อให้คุณส่งผ่าน XML เนื้อหาประเภทพวกเขาจะคืนค่า xml แทนที่จะเป็นค่าเริ่มต้น JSON ซึ่งฉันคิดว่าการก้าวไปข้างหน้าเป็นความคิดที่ดี

— Leeroy
แหล่งที่มา