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

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

또한 웹에서 우연히 발견 한 스마트 한 사용법을 자유롭게 게시하십시오. 우리는 목표로 가장 좋은 것을 사용하여 이것을 구현하려고합니다. :)

권장이 되어 있었다 "X-"로 이름을 시작합니다. 예 X-Forwarded-For, X-Requested-With. 이것은 RFC 2047 의 ao section 5에도 언급되어 있습니다.

업데이트 1 : 2011 년 6 월, 비표준 헤더에 "X-"접두사 사용을 권장 하지 않는 첫 번째 IETF 초안 이 게시되었습니다 . 그 이유는 접두사가 "X-"인 비표준 헤더가 표준이 될 때 "X-"접두어를 제거하면 이전 버전과의 호환성이 손상되어 응용 프로그램 프로토콜이 두 이름을 모두 지원하게됩니다 (예 : & 는 동일 함). 그래서, 공식 추천은 단지 그들을 이름을 지정하는 것입니다 띌 은 "X-"접두사없이.x-gzipgzip

업데이트 2 : 2012 년 6 월, "X-"접두사 사용 권장 사항이 RFC 6648 으로 공식 폐기되었습니다 . 다음은 관련성의 인용입니다.

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

...

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

4. 프로토콜 디자이너를위한 권장 사항

...

4. 접두사 "X-"또는 이와 유사한 구문이있는 매개 변수를 등록해서는 안됩니다.

5. 접두사 "X-"또는 이와 유사한 구문을 갖는 매개 변수는 표준화되지 않은 것으로 이해해야한다고 명시해서는 안됩니다.

6. 접두사 "X-"또는 이와 유사한 구문이없는 매개 변수는 표준화 된 것으로 이해해야한다고 명시해서는 안됩니다.

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

요약 :

• 공식 추천은 단지 그들을 이름을 지정하는 것입니다 띌 은 "X-"접두사없이
• "X-"접두사 헤더를 계속 사용할 수 있지만 더 이상 공식적으로 권장되지 않으며 공개 표준 인 것처럼 문서화하지 않을 수 있습니다.

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

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

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

IMHO의 IETF 사양은 OP의 질문에 대답하기에 불충분하게 구체적으로되어 있습니다. 이는 완전히 다른 유스 케이스를 구별하지 못하기 때문입니다. 클라이언트 및 서버와의 응용 프로그램 별 문자열을 전달하는 응용 프로그램 개발자. 사양은 전자와 관련이 있습니다 (A). 여기서 질문은 (B)에 대한 규칙이 있는지 여부입니다. 있습니다. 여기에는 매개 변수를 알파벳순으로 그룹화하고 (A) 유형의 많은 표준 관련 헤더에서 분리하는 과정이 포함됩니다. "X-"또는 "X-ACME-"접두어를 사용하는 것이 편리하고 (B)에 합법적이며 (A)와 충돌하지 않습니다. (A)에 더 많은 공급 업체가 "X-"를 사용하지 않을수록 (B)가 더 명확하게 구분됩니다.

예 :
Google (다양한 표준 기관에 약간의 무게를 가짐)은 오늘 답변으로 약간 수정하여 20141102 현재 아파치 모듈의 버전을 나타내는 "X-Mod-Pagespeed"를 사용하고 있습니다 주어진 응답을 변환하는 데 관여합니다. 누구든지 Google이 "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>

이 정의는 토큰과 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           = <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].

두 가지 결론이 있습니다. 첫째, 헤더 이름 은 영숫자, 문장 부호 등 ASCII 문자의 하위 집합으로 구성되어야한다는 것이 분명합니다 . 둘째, 헤더 값 의 정의에는 아무것도 없습니다 을 할 때 ASCII로 제한하거나 8 비트 문자를 제외 . 제어 문자 만 금지 된 8 진수로 명시 적으로 구성됩니다 (CR 및 LF는 제어로 간주 됨). 또한 TEXT 제작에 대한 의견은 옥텟이 ISO-8859-1에있는 것으로 해석되어야하며 해당 인코딩 외부의 문자를 표현하기위한 인코딩 메커니즘 (끔찍하게도 우연히 발생 함)이 있음을 의미합니다.

따라서 @BalusC에 특히 응답하기 위해 사양에 따라 헤더 값이 ISO-8859-1임을 분명히 알 수 있습니다. Tomcat의 헤더에 높은 8859-1 문자 (특히 프랑스어로 사용되는 악센트 모음)를 보냈고 Firefox에서 올바르게 해석 했으므로 어느 정도 이론적으로나 실제로 작동합니다. (이것은 URL을 포함하는 Location 헤더이지만 이러한 문자는 URL에서 합법적이지 않으므로 실제로는 불법이지만 다른 규칙에 따릅니다!).

즉, 모든 서버, 프록시 및 클라이언트에서 작동하는 ISO-8859-1에 의존하지 않으므로 방어 프로그래밍의 문제로 ASCII를 고수 할 것입니다.

RFC6648 은 사용자 정의 헤더가 "다중 구현에서 표준화, 공개, 공통 배치 또는 사용 가능"할 것이라고 가정합니다. 따라서 접두사 "X-"또는 유사한 구문을 사용하지 않는 것이 좋습니다.

그러나 "[헤더]가 표준화 될 가능성이 극히 적은 경우"는 예외입니다. 이러한 "구현 별 및 개인용"헤더의 경우 RFC는 공급 업체 접두사와 같은 네임 스페이스가 정당하다고 말합니다.

추가 HTTP 헤더를 추가 하거나 수정하면 더 좋은 코드 디버깅 도구입니다.

URL 요청이 경로 재 지정 또는 이미지를 리턴 할 때 디버그 코드의 결과를 브라우저에 표시되지 않는 html "페이지"가 ​​없습니다.

한 가지 방법은 데이터를 로컬 로그 파일에 쓰고 나중에 해당 파일을 보는 것입니다. 또 다른 방법은 디버깅중인 데이터 및 변수를 반영하는 HTTP 헤더를 임시로 추가하는 것입니다.

나는 정기적으로 X-fubar-somevar : 또는 X-testing-someresult :와 같은 추가 HTTP 헤더를 추가하여 문제를 테스트하고 추적하기가 매우 어려운 많은 버그를 발견했습니다.

헤더 필드 이름 레지스트리는 RFC3864에 정의되어 있으며 "X-"에는 특별한 것이 없습니다.

내가 알 수있는 한, 개인 헤더에 대한 지침은 없습니다. 의심, 그들을 피하십시오. 또는 HTTP Extension Framework ( RFC 2774 )를 살펴보십시오 .

더 많은 사용 사례를 이해하는 것이 흥미로울 것입니다. 왜 메시지 본문에 정보를 추가 할 수 없습니까?