사용자 지정 HTTP 헤더 : 명명 규칙

사용자 지정 HTTP 헤더 : 명명 규칙

---

일부 사용자는 우리가 보내는 요청 의 HTTP 헤더 에 자신의 계정과 관련된 데이터를 포함 하거나 API에서받은 응답을 포함하도록 요청했습니다. 이름 지정 , 형식 등의 측면에서 사용자 지정 HTTP 헤더를 추가하는 일반적인 규칙은 무엇입니까?

또한 웹에서 우연히 발견 한 이들의 현명한 사용법을 자유롭게 게시하십시오. 우리는 목표로 최선을 다하는 것을 사용하여 이것을 구현하려고합니다. :)

---

2012 년 6 월에 "X-"접두사 사용에 대한 권장 사항이 RFC 6648 로 공식화되었습니다 . 다음은 관련성 인용문입니다.

3. 새로운 매개 변수 생성자를위한 권장 사항

...

3. 매개 변수 이름 앞에 "X-"또는 유사한 구문을 붙이면 안됩니다.

4. 프로토콜 설계자를위한 권장 사항

...

4. "X-"접두사가있는 매개 변수 또는 유사한 구성이 등록되는 것을 금지하면 안됩니다 (SHOULD NOT).

5. "X-"접두사 또는 유사한 구조가있는 매개 변수를 표준화되지 않은 것으로 이해해야한다고 규정해서는 안됩니다.

6. "X-"접두사 또는 유사한 구조가없는 매개 변수가 표준화 된 것으로 이해되어야한다고 규정해서는 안됩니다.

"SHOULD NOT"( "discouraged")은 "MUST NOT"( "forbidden")과 동일하지 않습니다 . 해당 키워드에 대한 다른 사양 은 RFC 2119 도 참조하십시오 . 즉, "X-"접두사가 붙은 헤더를 계속 사용할 수 있지만 권장되지 않으며 공개 표준 인 것처럼 문서화 할 수 없습니다.

---

2011 년 6 월 첫 번째 IETF 초안 이 비표준 헤더에 "X-"접두사 를 사용 하는 권장 사항 을 폐기 하기 위해 게시되었습니다 . 그 이유는 "X-"접두사가 붙은 비표준 헤더가 표준이 될 때 "X-"접두사를 제거하면 이전 버전과의 호환성이 깨져 응용 프로그램 프로토콜이 두 이름을 모두 지원하도록 강제하기 때문입니다 (예 : x-gzip& gzip는 이제 동일합니다). 따라서 "X-"접두사없이 이름을 현명하게 지정하는 것이 좋습니다 .

---

권장이 되어 있었다 "X-"로 이름을 시작합니다. 예 X-Forwarded-For, X-Requested-With. 이는 RFC 2047 의 ao 섹션 5에서도 언급됩니다 .

---

질문은 다시 읽어야합니다. 실제 질문은 CSS 속성의 공급 업체 접두사와 유사하지 않으며, 공급 업체 지원 및 공식 표준에 대한 미래 보장 및 생각이 적절합니다. 실제 질문은 URL 쿼리 매개 변수 이름을 선택하는 것과 비슷합니다. 아무도 그들이 무엇인지 신경 써서는 안됩니다. 그러나 사용자 정의 이름 간격은 완벽하게 유효하고 일반적이며 올바른 작업입니다.

근거 : 개발자를 제외하고는 제 3자가 구현할 공급 업체, 표준 기관 또는 프로토콜과 관련이없는 사용자 지정 애플리케이션 별 헤더 ( " 계정 관련 데이터 ")에 대한 개발자 간의 규칙
에 관한 것입니다. 문제의 경우 서버, 프록시 또는 클라이언트가 다른 용도로 사용할 수있는 헤더 이름을 피하면됩니다. 이러한 이유로 "X-Gzip / Gzip"및 "X-Forwarded-For / Forwarded-For"예제는 논쟁의 여지가 있습니다. 제기 된 질문은 URL 쿼리 매개 변수 명명 규칙과 유사한 개인 API 컨텍스트의 규칙에 관한 것입니다. 선호도와 이름 간격의 문제입니다. "X"가없는 프록시 또는 공급 업체에서 "X-ClientDataFoo"를 지원하는 것에 대한 우려

"X-"접두사에 대해 특별하거나 마술적인 것은 없지만 사용자 지정 헤더임을 명확히하는 데 도움이됩니다. 실제로 RFC-6648 등은 "X-"접두사 사용 사례를 강화하는 데 도움이됩니다. HTTP 클라이언트 및 서버 공급 업체가 접두사를 포기함에 따라 앱별, 개인 API, 개인 데이터- 통과 메커니즘은 적은 수의 공식 예약 헤더 이름과의 네임 스페이스 충돌에 대해 더 잘 보호되고 있습니다. 즉, 개인적 선호와 권장 사항은 한 단계 더 나아가 "X-ACME-ClientDataFoo"(위젯 회사가 "ACME"인 경우)를 수행하는 것입니다.

IMHO IETF 사양은 완전히 다른 사용 사례를 구분하지 못하기 때문에 OP의 질문에 대답하기에 충분하지 않습니다. (A) 한편으로는 "Forwarded-For"와 같은 새로운 글로벌 적용 가능한 기능을 도입하는 공급 업체와 (B) 클라이언트 및 서버간에 앱별 문자열을 전달하는 앱 개발자. 사양은 전자 (A)에만 해당됩니다. 여기서 질문은 (B)에 대한 관례가 있는지 여부입니다. 있습니다. 여기에는 매개 변수를 알파벳순으로 그룹화하고 여러 표준 관련 헤더 유형 (A)에서 분리하는 작업이 포함됩니다. "X-"또는 "X-ACME-"접두사를 사용하는 것은 (B)에 대해 편리하고 합법적이며 (A)와 충돌하지 않습니다. (A)에 대해 "X-"사용을 중단하는 공급 업체가 많을수록 (B) 공급 업체가 더 명확하게 구분됩니다.

예 :
Google (다양한 표준 기관에서 약간의 무게를 가지고 있음)은-오늘 20141102 내 대답에 대한 약간의 편집에서-현재 Apache 모듈의 버전을 나타 내기 위해 "X-Mod-Pagespeed"를 사용하고 있습니다. 주어진 응답을 변형하는 데 관여합니다. 정말로 구글이 "X-"없이 "Mod-Pagespeed"를 사용해야한다고 제안하거나 IETF에게 그 사용을 축복 해달라고 요청하는 사람이 있습니까?

요약 :
앱 내에서 사용자 지정 HTTP 헤더 (쿠키에 대한 적절한 대안)를 사용하여 서버로 /로부터 데이터를 전달하고 이러한 헤더는 명시 적으로 사용자의 컨텍스트 외부에서 사용하도록 의도되지 않은 경우 응용 프로그램에서 "X-"또는 "X-FOO-"접두사로 이름 간격을 지정하는 것은 합리적이고 일반적인 관례입니다.

---

HTTP 헤더의 형식은 HTTP 사양에 정의되어 있습니다. 사양이 RFC 2616 인 HTTP 1.1에 대해 이야기하겠습니다 . 섹션 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>

이 정의는 토큰과 텍스트라는 두 가지 주요 기둥에 있습니다. 둘 다 섹션 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는 선형 공백이고 정의는 재현하지 않으며 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].

So, two conclusions. Firstly, it's clear that the header name must be composed from a subset of ASCII characters - alphanumerics, some punctuation, not a lot else. Secondly, there is nothing in the definition of a header value that restricts it to ASCII or excludes 8-bit characters: it's explicitly composed of octets, with only control characters barred (note that CR and LF are considered controls). Furthermore, the comment on the TEXT production implies that the octets are to be interpreted as being in ISO-8859-1, and that there is an encoding mechanism (which is horrible, incidentally) for representing characters outside that encoding.

So, to respond to @BalusC in particular, it's quite clear that according to the specification, header values are in ISO-8859-1. I've sent high-8859-1 characters (specifically, some accented vowels as used in French) in a header out of Tomcat, and had them interpreted correctly by Firefox, so to some extent, this works in practice as well as in theory (although this was a Location header, which contains a URL, and these characters are not legal in URLs, so this was actually illegal, but under a different rule!).

That said, i wouldn't rely on ISO-8859-1 working across all servers, proxies, and clients, so i would stick to ASCII as a matter of defensive programming.

---

The header field name registry is defined in RFC3864, and there's nothing special with "X-".

As far as I can tell, there are no guidelines for private headers; in doubt, avoid them. Or have a look at the HTTP Extension Framework (RFC 2774).

It would be interesting to understand more of the use case; why can't the information be added to the message body?

---

Modifying, or more correctly, adding additional HTTP headers is a great code debugging tool if nothing else.

When a URL request returns a redirect or an image there is no html "page" to temporarily write the results of debug code to - at least not one that is visible in a browser.

One approach is to write the data to a local log file and view that file later. Another is to temporarily add HTTP headers reflecting the data and variables being debugged.

I regularly add extra HTTP headers like X-fubar-somevar: or X-testing-someresult: to test things out - and have found a lot of bugs that would have otherwise been very difficult to trace.

---

RFC6648 recommends that you assume that your custom header "might become standardized, public, commonly deployed, or usable across multiple implementations." Therefore, it recommends not to prefix it with "X-" or similar constructs.

However, there is an exception "when it is extremely unlikely that [your header] will ever be standardized." For such "implementation-specific and private-use" headers, the RFC says a namespace such as a vendor prefix is justified.

참고URL : https://stackoverflow.com/questions/3561381/custom-http-headers-naming-conventions