ส่วนหัว HTTP ที่กำหนดเอง: แบบแผนการตั้งชื่อ

ผู้ใช้ของเราหลายคนขอให้เรารวมข้อมูลที่เกี่ยวข้องกับบัญชีของพวกเขาในส่วนหัว HTTPของคำขอที่เราส่งพวกเขาหรือแม้กระทั่งการตอบสนองที่พวกเขาได้รับจาก API ของเรา คือการประชุมทั่วไปเพื่อเพิ่มสิ่งที่กำหนดเองส่วนหัว HTTP ในแง่ของการตั้งชื่อ , รูปแบบ ... ฯลฯ

นอกจากนี้อย่าลังเลที่จะโพสต์การใช้งานอย่างชาญฉลาดของสิ่งเหล่านี้ที่คุณสะดุดบนเว็บ เรากำลังพยายามที่จะใช้สิ่งนี้โดยใช้สิ่งที่ดีที่สุดในเป้าหมาย :)

ข้อเสนอแนะคือการ เป็นที่จะเริ่มต้นชื่อของพวกเขาด้วย "X-" เช่น,X-Forwarded-For X-Requested-Withสิ่งนี้ถูกกล่าวถึงในหัวข้อ 5 ของRFC 2047ด้วย

อัปเดต 1 : ในเดือนมิถุนายน 2554 มีการโพสต์ร่าง IETF ฉบับแรกเพื่อคัดค้านคำแนะนำในการใช้คำนำหน้า "X-" สำหรับส่วนหัวที่ไม่ได้มาตรฐาน เหตุผลก็คือเมื่อส่วนหัวที่ไม่ได้มาตรฐานนำหน้าด้วย "X-" กลายเป็นมาตรฐานการลบคำนำหน้า "X-" จะหยุดการทำงานร่วมกันย้อนหลังบังคับให้โปรโตคอลแอปพลิเคชันสนับสนุนทั้งชื่อ (เช่นตอนนี้x-gzip& gzipเทียบเท่า) ดังนั้นคำแนะนำอย่างเป็นทางการคือเพียงตั้งชื่ออย่างสมเหตุสมผลโดยไม่มีคำนำหน้า "X-"

การปรับปรุงที่ 2 : ในเดือนมิถุนายนปี 2012 คัดค้านของคำแนะนำที่จะใช้ "X-" คำนำหน้าได้กลายเป็นอย่างเป็นทางการRFC 6648 ด้านล่างนี้เป็นแหล่งอ้างอิงของความเกี่ยวข้อง:

3. คำแนะนำสำหรับผู้สร้างพารามิเตอร์ใหม่

...

3. ไม่ควรขึ้นต้นชื่อพารามิเตอร์ด้วย "X-" หรือโครงสร้างที่คล้ายกัน

4. คำแนะนำสำหรับผู้ออกแบบโปรโตคอล

...

4. ไม่ควรห้ามพารามิเตอร์ด้วยคำนำหน้า "X-" หรือโครงสร้างที่คล้ายกันจากการลงทะเบียน

5. ต้องไม่กำหนดว่าพารามิเตอร์ที่มีคำนำหน้า "X-" หรือโครงสร้างที่คล้ายกันจะต้องเข้าใจตามที่ไม่เป็นมาตรฐาน

6. ต้องไม่กำหนดว่าพารามิเตอร์ที่ไม่มีคำนำหน้า "X-" หรือโครงสร้างที่คล้ายกันจะต้องเข้าใจตามมาตรฐาน

โปรดทราบว่า "ไม่ควร" ("หมดกำลังใจ") ไม่เหมือนกับ "ต้องไม่" ("ต้องห้าม") ดูRFC 2119สำหรับข้อมูลจำเพาะอื่น ๆ ของคำหลักเหล่านั้น กล่าวอีกนัยหนึ่งคุณสามารถใช้คำนำหน้า "X-" ต่อไปได้ แต่ไม่แนะนำอย่างเป็นทางการอีกต่อไปและคุณอาจไม่บันทึกเอกสารเหล่านั้นราวกับเป็นมาตรฐานสาธารณะ

สรุป :

• คำแนะนำอย่างเป็นทางการคือเพียงตั้งชื่ออย่างสมเหตุสมผลโดยไม่มีคำนำหน้า "X-"
• คุณสามารถใช้ส่วนหัวที่ขึ้นต้นด้วย "X-" ได้ แต่ไม่แนะนำอย่างเป็นทางการอีกต่อไปและคุณอาจไม่บันทึกเอกสารอย่างแน่นอนราวกับว่าเป็นมาตรฐานสาธารณะ

คำถามหมีอ่านอีกครั้ง คำถามที่ถามจริงไม่เหมือนกับคำนำหน้าผู้ขายในคุณสมบัติ CSS ซึ่งการพิสูจน์อักษรในอนาคตและการพิจารณาเกี่ยวกับการสนับสนุนผู้ขายและมาตรฐานอย่างเป็นทางการเหมาะสม คำถามที่ถามจริงจะคล้ายกับการเลือกชื่อพารามิเตอร์การสืบค้น URL ไม่มีใครควรใส่ใจในสิ่งที่พวกเขาเป็น แต่การเว้นวรรคชื่อที่กำหนดเองเป็นสิ่งที่ถูกต้องสมบูรณ์ - และทั่วไปและถูกต้อง - สิ่งที่ต้องทำ

เหตุผล:
มันเป็นเรื่องเกี่ยวกับการประชุมระหว่างนักพัฒนาสำหรับส่วนหัวที่กำหนดเองเฉพาะแอปพลิเคชัน - " ข้อมูลที่เกี่ยวข้องกับบัญชีของพวกเขา " - ซึ่งไม่มีส่วนเกี่ยวข้องกับผู้ขายหน่วยมาตรฐานหรือโปรโตคอลที่จะดำเนินการโดยบุคคลที่สาม ในคำถามต้องหลีกเลี่ยงชื่อส่วนหัวที่อาจมีการใช้งานโดยเซิร์ฟเวอร์พร็อกซีหรือไคลเอนต์ ด้วยเหตุผลนี้ตัวอย่าง "X-Gzip / Gzip" และ "X-Forwarded-For / Forwarded-For" ที่ระบุคือ moot คำถามที่ถูกวางเป็นเรื่องเกี่ยวกับการประชุมในบริบทของ API ส่วนตัวคล้ายกับการตั้งชื่อพารามิเตอร์การสืบค้นพารามิเตอร์ URL มันเป็นเรื่องของการตั้งค่าและการเว้นวรรคชื่อ; ข้อกังวลเกี่ยวกับ "X-ClientDataFoo" ได้รับการสนับสนุนโดยพร็อกซีหรือผู้ขายที่ไม่มี "X"

ไม่มีอะไรพิเศษหรือน่าอัศจรรย์เกี่ยวกับคำนำหน้า "X-" แต่ช่วยให้ชัดเจนว่าเป็นส่วนหัวที่กำหนดเอง ในความเป็นจริง RFC-6648 et al ช่วยหนุนกรณีสำหรับการใช้คำนำหน้า "X-" เพราะ - ในฐานะผู้ขายของไคลเอนต์ HTTP และเซิร์ฟเวอร์ละทิ้งคำนำหน้า - เฉพาะแอพส่วนตัว API ส่วนตัวของคุณ - ข้อมูล - กลไกการส่งผ่านกำลังกลายเป็นฉนวนที่ดียิ่งขึ้นต่อการชนกันของพื้นที่ชื่อที่มีชื่อส่วนหัวสงวนอย่างเป็นทางการจำนวนน้อย ที่กล่าวว่าการตั้งค่าส่วนตัวและคำแนะนำของฉันคือการไปอีกขั้นและทำเช่น "X-ACME-ClientDataFoo" (ถ้า บริษัท เครื่องมือของคุณคือ "ACME")

IMHO ข้อมูลจำเพาะของ IETF นั้นไม่เฉพาะเจาะจงเพียงพอที่จะตอบคำถามของ OP เนื่องจากไม่สามารถแยกแยะความแตกต่างระหว่างกรณีการใช้งานที่แตกต่างกันโดยสิ้นเชิง: ผู้ขาย (A) ได้แนะนำคุณสมบัติใหม่ที่สามารถใช้ได้ทั่วโลกเช่น "Forwarded-For" นักพัฒนาแอพส่งผ่านสตริงเฉพาะแอปไปยัง / จากลูกค้าและเซิร์ฟเวอร์ ข้อมูลจำเพาะเกี่ยวข้องเฉพาะกับอดีต (A) คำถามที่นี่คือว่ามีการประชุมสำหรับ (B) มี พวกเขาเกี่ยวข้องกับการจัดกลุ่มพารามิเตอร์เข้าด้วยกันตามตัวอักษรและแยกพวกเขาออกจากส่วนหัวที่เกี่ยวข้องกับมาตรฐานหลายประเภท (A) การใช้คำนำหน้า "X-" หรือ "X-ACME-" นั้นสะดวกและถูกต้องตามกฎหมายสำหรับ (B) และไม่ขัดแย้งกับ (A) ยิ่งผู้ขายหยุดใช้ "X-" สำหรับ (A) ยิ่งคนที่ชัดเจน (B) จะชัดเจนยิ่งขึ้น

ตัวอย่าง:
Google (ที่มีน้ำหนักเล็กน้อยในหน่วยมาตรฐานต่างๆ) - ณ วันนี้ 20141102 ในการแก้ไขคำตอบของฉันเล็กน้อย - ปัจจุบันใช้ "X-Mod-Pagespeed" เพื่อระบุรุ่นของโมดูล Apache ของพวกเขา มีส่วนร่วมในการเปลี่ยนการตอบสนองที่กำหนด มีใครแนะนำว่า Google ควรใช้ "Mod-Pagespeed" โดยไม่มี "X-" และ / หรือขอให้ IETF เป็นพรแก่การใช้งานจริงหรือ

สรุป:
หากคุณใช้ส่วนหัว HTTP ที่กำหนดเอง (เป็นทางเลือกที่เหมาะสมในบางครั้งกับคุกกี้) ภายในแอปของคุณเพื่อส่งผ่านข้อมูลไปยัง / จากเซิร์ฟเวอร์ของคุณและส่วนหัวเหล่านี้ชัดเจนไม่ตั้งใจจะนำมาใช้ แอปพลิเคชันให้เว้นวรรคชื่อด้วยคำนำหน้า "X-" หรือ "X-FOO-" เป็นแบบแผนที่สมเหตุสมผลและเป็นเรื่องธรรมดา

รูปแบบสำหรับส่วนหัว HTTP ถูกกำหนดไว้ในข้อมูลจำเพาะ HTTP ฉันจะพูดคุยเกี่ยวกับ 1.1 HTTP ซึ่งสเปคเป็นRFC 2616 ในส่วน 4.2 'ส่วนหัวของข้อความ' จะมีการกำหนดโครงสร้างทั่วไปของส่วนหัว:

   message-header = field-name ":" [ field-value ]
   field-name     = token
   field-value    = *( field-content | LWS )
   field-content  = <the OCTETs making up the field-value
                    and consisting of either *TEXT or combinations
                    of token, separators, and quoted-string>

คำจำกัดความนี้วางอยู่บนสองเสาหลักโทเค็นและ TEXT ทั้งสองถูกกำหนดไว้ในส่วน 2.2 'กฎพื้นฐาน' โทเค็นคือ:

   token          = 1*<any CHAR except CTLs or separators>

ในทางกลับกันวางบน CHAR, CTL และตัวคั่น:

   CHAR           = <any US-ASCII character (octets 0 - 127)>

   CTL            = <any US-ASCII control character
                    (octets 0 - 31) and DEL (127)>

   separators     = "(" | ")" | "<" | ">" | "@"
                  | "," | ";" | ":" | "\" | <">
                  | "/" | "[" | "]" | "?" | "="
                  | "{" | "}" | SP | HT

TEXT คือ:

   TEXT           = <any OCTET except CTLs,
                    but including LWS>

โดยที่ LWS คือ white space เชิงเส้นซึ่งคำจำกัดความฉันจะไม่ทำซ้ำและ OCTET คือ:

   OCTET          = <any 8-bit sequence of data>

มีหมายเหตุประกอบคำนิยาม:

The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].

ดังนั้นสองข้อสรุป ประการแรกเป็นที่ชัดเจนว่าชื่อส่วนหัวจะต้องประกอบด้วยชุดย่อยของอักขระ ASCII - ตัวอักษรและตัวเลขเครื่องหมายวรรคตอนบางอย่างไม่มาก ประการที่สองไม่มีอะไรในคำจำกัดความของค่าส่วนหัวที่ จำกัด ไว้ที่ ASCII หรือยกเว้นอักขระ 8 บิต: ประกอบด้วย octets อย่างชัดเจนโดยมีเฉพาะอักขระควบคุมห้าม (หมายเหตุว่า CR และ LF ถือว่าเป็นตัวควบคุม) นอกจากนี้ความคิดเห็นเกี่ยวกับการผลิต TEXT ก็หมายความว่า octets จะถูกตีความว่าอยู่ใน ISO-8859-1 และมีกลไกการเข้ารหัส (ซึ่งน่ากลัวมากโดยบังเอิญ) สำหรับการแสดงอักขระนอกการเข้ารหัสนั้น

ดังนั้นเพื่อตอบสนองต่อ @BalusC โดยเฉพาะมันค่อนข้างชัดเจนว่าตามข้อกำหนดคุณสมบัติค่าส่วนหัวอยู่ใน ISO-8859-1 ฉันส่งอักขระที่มีความสูง 8859-1 ตัว (โดยเฉพาะเสียงสระที่เน้นเสียงบางอย่างที่ใช้เป็นภาษาฝรั่งเศส) ในส่วนหัวของ Tomcat และให้พวกเขาตีความอย่างถูกต้องโดย Firefox ดังนั้นในระดับหนึ่งงานนี้ในทางปฏิบัติเช่นเดียวกับในทางทฤษฎี (แม้ว่านี่จะเป็นส่วนหัว Location ซึ่งมี URL และอักขระเหล่านี้ไม่ถูกต้องใน URL ดังนั้นนี่จึงผิดกฎหมาย แต่ภายใต้กฎที่แตกต่างกัน!)

ที่กล่าวว่าฉันจะไม่พึ่งพา ISO-8859-1 ทำงานบนเซิร์ฟเวอร์พร็อกซีและลูกค้าทั้งหมดดังนั้นฉันจะติดกับ ASCII เป็นเรื่องของการเขียนโปรแกรมป้องกัน

RFC6648แนะนำให้คุณสมมติว่าส่วนหัวที่กำหนดเองของคุณ "อาจกลายเป็นมาตรฐานสาธารณะปรับใช้ทั่วไปหรือใช้งานได้ในหลาย ๆ การใช้งาน" ดังนั้นจึงไม่แนะนำให้นำหน้าด้วย "X-" หรือโครงสร้างที่คล้ายกัน

อย่างไรก็ตามมีข้อยกเว้น "เมื่อไม่น่าเป็นไปได้อย่างมากที่ [ส่วนหัวของคุณ] จะได้มาตรฐาน" สำหรับส่วนหัว "การใช้งานเฉพาะและใช้งานส่วนตัว" RFC กล่าวว่าเนมสเปซเช่นคำนำหน้าผู้จัดจำหน่ายนั้นเป็นธรรม

การแก้ไขหรือเพิ่มเติมอย่างถูกต้องการเพิ่มส่วนหัว HTTP เพิ่มเติมเป็นเครื่องมือในการดีบั๊กโค้ดหากไม่มีสิ่งอื่น

เมื่อคำขอ URL ส่งคืนการเปลี่ยนเส้นทางหรือรูปภาพจะไม่มี "หน้า" HTML เพื่อเขียนผลลัพธ์ของรหัสการแก้ปัญหาชั่วคราว - อย่างน้อยไม่ใช่รูปแบบที่ปรากฏในเบราว์เซอร์

วิธีหนึ่งคือการเขียนข้อมูลไปยังไฟล์บันทึกในเครื่องและดูไฟล์นั้นในภายหลัง อีกวิธีหนึ่งคือการเพิ่มส่วนหัว HTTP ชั่วคราวเพื่อสะท้อนข้อมูลและตัวแปรที่กำลังดีบั๊ก

ฉันเพิ่มส่วนหัว HTTP พิเศษเป็นประจำเช่น X-fubar-somevar: หรือ X-testing-someresult: เพื่อทดสอบสิ่งต่าง ๆ - และพบข้อบกพร่องจำนวนมากที่อาจยากต่อการติดตาม

รีจีสทรีชื่อฟิลด์ส่วนหัวถูกกำหนดในRFC3864และไม่มีอะไรพิเศษกับ "X-"

เท่าที่ฉันสามารถบอกได้ไม่มีแนวทางสำหรับส่วนหัวส่วนตัว มีข้อสงสัยหลีกเลี่ยงพวกเขา หรือดู HTTP Extension Framework ( RFC 2774 )

มันจะน่าสนใจที่จะเข้าใจกรณีการใช้งานมากขึ้น เหตุใดจึงไม่สามารถเพิ่มข้อมูลลงในเนื้อหาของข้อความได้