Tiêu đề HTTP tùy chỉnh: quy ước đặt tên

Một số người dùng của chúng tôi đã yêu cầu chúng tôi đưa dữ liệu liên quan đến tài khoản của họ vào tiêu đề HTTP của các yêu cầu chúng tôi gửi cho họ hoặc thậm chí các phản hồi họ nhận được từ API của chúng tôi. Quy ước chung để thêm các tiêu đề HTTP tùy chỉnh là gì, về cách đặt tên , định dạng ... vv

Ngoài ra, vui lòng đăng bất kỳ cách sử dụng thông minh nào trong số này mà bạn tình cờ thấy trên web; Chúng tôi đang cố gắng thực hiện điều này bằng cách sử dụng những gì tốt nhất ngoài mục tiêu :)

Các khuyến nghị được là để bắt đầu tên của họ với "X". Ví dụ X-Forwarded-For, X-Requested-With. Điều này cũng được đề cập trong phần 5 của RFC 2047 .

Cập nhật 1 : Vào tháng 6 năm 2011, dự thảo IETF đầu tiên đã được đăng để phản đối khuyến nghị sử dụng tiền tố "X-" cho các tiêu đề không chuẩn. Lý do là khi các tiêu đề không chuẩn có tiền tố "X-" trở thành tiêu chuẩn, loại bỏ tiền tố "X-" sẽ phá vỡ tính tương thích ngược, buộc các giao thức ứng dụng phải hỗ trợ cả hai tên (Ví dụ, x-gzip& gziphiện tương đương). Vì vậy, khuyến nghị chính thức là chỉ cần đặt tên cho chúng một cách hợp lý mà không cần tiền tố "X-".

Cập nhật 2 : Vào tháng 6 năm 2012, việc không khuyến nghị sử dụng tiền tố "X-" đã trở thành chính thức như RFC 6648 . Dưới đây là trích dẫn liên quan:

3. Khuyến nghị cho người tạo thông số mới

...

3. KHÔNG NÊN tiền tố tên tham số của họ với "X-" hoặc các cấu trúc tương tự.

4. Khuyến nghị cho các nhà thiết kế giao thức

...

4. KHÔNG NÊN cấm các tham số có tiền tố "X-" hoặc các cấu trúc tương tự được đăng ký.

5. PHẢI KHÔNG quy định rằng một tham số có tiền tố "X-" hoặc các cấu trúc tương tự cần được hiểu là không đạt tiêu chuẩn.

6. PHẢI KHÔNG quy định rằng một tham số không có tiền tố "X-" hoặc các cấu trúc tương tự cần được hiểu là tiêu chuẩn hóa.

Lưu ý rằng "KHÔNG NÊN" ("không khuyến khích") không giống như "PHẢI KHÔNG" ("cấm"), xem thêm RFC 2119 để biết thông số kỹ thuật khác về các từ khóa đó. Nói cách khác, bạn có thể tiếp tục sử dụng các tiêu đề có tiền tố "X-", nhưng nó không được đề xuất chính thức nữa và bạn chắc chắn không thể ghi lại chúng như thể chúng là tiêu chuẩn chung.

Tóm tắt :

• khuyến nghị chính thức là chỉ đặt tên cho chúng hợp lý mà không cần tiền tố "X-"
• bạn có thể tiếp tục sử dụng các tiêu đề có tiền tố "X-", nhưng nó không được đề xuất chính thức nữa và bạn chắc chắn không thể ghi lại chúng như thể chúng là tiêu chuẩn chung

Câu hỏi gấu đọc lại. Câu hỏi thực tế được hỏi không giống với tiền tố của nhà cung cấp trong các thuộc tính CSS, trong đó việc chứng minh và suy nghĩ trong tương lai về hỗ trợ của nhà cung cấp và các tiêu chuẩn chính thức là phù hợp. Câu hỏi thực tế được hỏi gần giống với việc chọn tên tham số truy vấn URL. Không ai nên quan tâm họ là gì. Nhưng khoảng cách tên các tùy chỉnh là một điều hoàn toàn hợp lệ - và phổ biến, và chính xác - điều cần làm.

Đặt vấn đề:
Đó là về các quy ước giữa các nhà phát triển cho các tiêu đề tùy chỉnh, dành riêng cho ứng dụng - " dữ liệu liên quan đến tài khoản của họ " - không liên quan gì đến các nhà cung cấp, cơ quan tiêu chuẩn hoặc giao thức được thực hiện bởi các bên thứ ba, ngoại trừ nhà phát triển trong câu hỏi chỉ cần tránh các tên tiêu đề có thể có mục đích sử dụng khác của máy chủ, proxy hoặc máy khách. Vì lý do này, các ví dụ "X-Gzip / Gzip" và "X-Forwarded-For / Forwarded-For" được đưa ra là moot. Câu hỏi được đặt ra là về các quy ước trong ngữ cảnh của API riêng, gần giống với các quy ước đặt tên tham số truy vấn URL. Đó là vấn đề ưu tiên và khoảng cách tên; lo ngại về "X-ClientDataFoo" được hỗ trợ bởi bất kỳ proxy hoặc nhà cung cấp nào mà không có "X"

Không có gì đặc biệt hay kỳ diệu về tiền tố "X-", nhưng nó giúp làm rõ rằng đó là một tiêu đề tùy chỉnh. Trên thực tế, RFC-6648 và cộng sự giúp củng cố trường hợp sử dụng tiền tố "X-", bởi vì - khi các nhà cung cấp máy khách và máy chủ HTTP từ bỏ tiền tố - API riêng, ứng dụng, dữ liệu cá nhân của bạn cơ chế chuyền đang trở nên thậm chí được cách ly tốt hơn trước các va chạm không gian tên với số lượng nhỏ các tên tiêu đề được bảo lưu chính thức. Điều đó nói rằng, sở thích và đề xuất cá nhân của tôi là tiến thêm một bước và làm ví dụ: "X-ACME-ClientDataFoo" (nếu công ty phụ tùng của bạn là "ACME").

IMHO thông số IETF không đủ cụ thể để trả lời câu hỏi của OP, vì nó không phân biệt được các trường hợp sử dụng hoàn toàn khác nhau: (A) các nhà cung cấp giới thiệu các tính năng mới có thể áp dụng trên toàn cầu như "Chuyển tiếp cho" trên một mặt, so với (B) nhà phát triển ứng dụng chuyển các chuỗi dành riêng cho ứng dụng đến / từ máy khách và máy chủ. Thông số kỹ thuật chỉ liên quan đến chính nó, (A). Câu hỏi ở đây là liệu có các quy ước cho (B) không. Có. Chúng liên quan đến việc nhóm các tham số lại với nhau theo thứ tự bảng chữ cái và tách chúng ra khỏi nhiều tiêu đề liên quan đến tiêu chuẩn loại (A). Sử dụng tiền tố "X-" hoặc "X-ACME-" là thuận tiện và hợp pháp cho (B) và không xung đột với (A). Càng nhiều nhà cung cấp ngừng sử dụng "X-" cho (A), các nhà cung cấp (B) sẽ càng rõ ràng hơn.

Ví dụ:
Google (người mang một chút trọng lượng trong các cơ quan tiêu chuẩn khác nhau) - tính đến ngày hôm nay, 20141102 trong bản chỉnh sửa nhỏ này cho câu trả lời của tôi - hiện đang sử dụng "X-Mod-Pagespeed" để chỉ ra phiên bản mô-đun Apache của họ tham gia vào việc chuyển đổi một phản ứng nhất định. Có ai thực sự đề xuất rằng Google nên sử dụng "Mod-Pagespeed", mà không có "X-" và / hoặc yêu cầu IETF ban phước cho việc sử dụng nó không?

Tóm tắt:
Nếu bạn đang sử dụng Tiêu đề HTTP tùy chỉnh (như một cách thay thế phù hợp với cookie) trong ứng dụng của bạn để truyền dữ liệu đến / từ máy chủ của bạn và những tiêu đề này rõ ràng KHÔNG được sử dụng ngoài ngữ cảnh của bạn ứng dụng, đặt tên cho chúng với tiền tố "X-" hoặc "X-FOO-" là một quy ước hợp lý và phổ biến.

Định dạng cho các tiêu đề HTTP được xác định trong đặc tả HTTP. Tôi sẽ nói về HTTP 1.1, trong đó đặc tả là RFC 2616 . Trong phần 4.2, 'Tiêu đề thư', cấu trúc chung của tiêu đề được xác định:

   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>

Định nghĩa này dựa trên hai trụ cột chính, mã thông báo và văn bản. Cả hai đều được định nghĩa trong phần 2.2, 'Quy tắc cơ bản'. Mã thông báo là:

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

Lần lượt nghỉ ngơi trên CHAR, CTL và dải phân cách:

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

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

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

VĂN BẢN là:

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

Trong đó LWS là không gian trắng tuyến tính, với định nghĩa tôi sẽ không tái tạo và OCTET là:

   OCTET          = <any 8-bit sequence of data>

Có một lưu ý kèm theo định nghĩa:

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].

Vì vậy, hai kết luận. Đầu tiên, rõ ràng tên tiêu đề phải được tạo từ một tập hợp các ký tự ASCII - chữ số, một số dấu câu, không phải là nhiều dấu chấm khác. Thứ hai, không có gì trong định nghĩa của giá trị tiêu đề giới hạn nó ở ASCII hoặc loại trừ các ký tự 8 bit: nó bao gồm các octet rõ ràng, chỉ có các ký tự điều khiển bị chặn (lưu ý rằng CR và LF được coi là các điều khiển). Hơn nữa, nhận xét về sản xuất văn bản ngụ ý rằng các octet sẽ được hiểu là trong ISO-8859-1, và có một cơ chế mã hóa (thật kinh khủng, tình cờ) để thể hiện các ký tự bên ngoài mã hóa đó.

Vì vậy, để trả lời @BalusC nói riêng, khá rõ ràng rằng theo đặc điểm kỹ thuật, các giá trị tiêu đề nằm trong ISO-8859-1. Tôi đã gửi các ký tự cao 8859-1 (cụ thể là một số nguyên âm có dấu như được sử dụng bằng tiếng Pháp) trong một tiêu đề ra khỏi Tomcat và do chúng giải thích chính xác bởi Firefox, do đó, ở một mức độ nào đó, nó hoạt động trong thực tế cũng như trên lý thuyết (mặc dù đây là tiêu đề Vị trí, chứa URL và các ký tự này không hợp pháp trong các URL, vì vậy đây thực sự là bất hợp pháp, nhưng theo một quy tắc khác!).

Điều đó nói rằng, tôi sẽ không dựa vào ISO-8859-1 hoạt động trên tất cả các máy chủ, proxy và máy khách, vì vậy tôi sẽ gắn bó với ASCII như một vấn đề về lập trình phòng thủ.

RFC6648 khuyên bạn nên giả định rằng tiêu đề tùy chỉnh của bạn "có thể trở thành tiêu chuẩn hóa, công khai, thường được triển khai hoặc có thể sử dụng trên nhiều triển khai." Do đó, nó khuyến nghị không nên thêm tiền tố vào "X-" hoặc các cấu trúc tương tự.

Tuy nhiên, có một ngoại lệ "khi rất khó có khả năng [tiêu đề của bạn] sẽ được chuẩn hóa." Đối với các tiêu đề "cụ thể và sử dụng riêng" như vậy, RFC cho biết một không gian tên như tiền tố của nhà cung cấp là hợp lý.

Sửa đổi, hoặc chính xác hơn, thêm các tiêu đề HTTP bổ sung là một công cụ gỡ lỗi mã tuyệt vời nếu không có gì khác.

Khi một yêu cầu URL trả về một chuyển hướng hoặc một hình ảnh, không có "trang" html để tạm thời ghi kết quả của mã gỡ lỗi vào - ít nhất là không hiển thị trong trình duyệt.

Một cách tiếp cận là ghi dữ liệu vào tệp nhật ký cục bộ và xem tệp đó sau. Một cách khác là tạm thời thêm các tiêu đề HTTP phản ánh dữ liệu và các biến được gỡ lỗi.

Tôi thường xuyên thêm các tiêu đề HTTP bổ sung như X-fubar-somevar: hoặc X-tests-someresult: để kiểm tra mọi thứ - và đã tìm thấy rất nhiều lỗi có thể rất khó theo dõi.

Sổ đăng ký tên trường tiêu đề được xác định trong RFC3864 và không có gì đặc biệt với "X-".

Theo như tôi có thể nói, không có hướng dẫn cho các tiêu đề riêng; nghi ngờ, tránh chúng Hoặc hãy xem Khung mở rộng HTTP ( RFC 2774 ).

Sẽ rất thú vị khi hiểu thêm về trường hợp sử dụng; Tại sao thông tin không thể được thêm vào nội dung thư?