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

질문자 :Julien Genestoux

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

또한 웹에서 우연히 발견한 스마트 사용법을 자유롭게 게시하십시오. 우리는 최고의 것을 목표로 사용하여 이것을 구현하려고 노력하고 있습니다. :)

추천 은 그들의 이름을 "X-"로 시작하는 것이었습니다. 예: X-Forwarded-For , X-Requested-With . 이것은 RFC 2047의 섹션 5에도 언급되어 있습니다.

---

업데이트 1 : 2011년 6월 첫 번째 IETF 초안 이 게시되어 비표준 헤더에 "X-" 접두사 를 사용하는 권장 사항을 더 이상 사용하지 않습니다. 그 이유는 "X-" 접두사가 붙은 비표준 헤더가 표준이 될 때 "X-" 접두사를 제거하면 이전 버전과의 호환성이 중단되어 응용 프로그램 프로토콜이 두 이름을 모두 지원하도록 강제하기 때문입니다(예: x-gzip 및 gzip 은 이제 동일함). 따라서 공식 권장 사항은 "X-" 접두사 없이 현명하게 이름을 지정하는 것입니다.

---

업데이트 2 : 2012년 6월에 "X-" 접두사를 사용하도록 권장하지 않는 것이 RFC 6648 로 공식화되었습니다. 다음은 관련 인용문입니다.

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

...

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

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

...

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

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

6. "X-" 접두사 또는 유사한 구성이 없는 매개변수를 표준화된 것으로 이해해야 한다고 규정해서는 안 됩니다(MUST NOT).

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

---

요약 :

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

BalusC

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

이론적 해석:
그것은 개발자들 사이의 관습에 관한 것 입니다. 사용자 정의, 응용 프로그램별 헤더( " 자신의 계정과 관련된 데이터 ")는 문제의 개발자를 제외하고 제3자가 구현하는 공급업체, 표준 기관 또는 프로토콜과 아무 관련이 없습니다. 서버, 프록시 또는 클라이언트에서 다른 용도로 사용할 수 있는 헤더 이름을 피하면 됩니다. 이러한 이유로 주어진 "X-Gzip/Gzip" 및 "X-Forwarded-For/Forwarded-For" 예제는 무의미합니다. 제기된 질문은 URL 쿼리 매개변수 명명 규칙과 유사한 비공개 API 컨텍스트의 규칙에 관한 것입니다. 선호도와 이름 간격의 문제입니다. "X"가 없는 프록시 또는 공급업체에서 지원하는 "X-ClientDataFoo"에 대한 우려는 분명히 잘못된 위치에 있습니다.

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

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

예시:
Google(다양한 표준 기관에서 약간의 비중을 차지함)은 -- 오늘 20141102 제 답변에 대한 약간의 편집으로 -- 현재 "X-Mod-Pagespeed"를 사용하여 관련된 Apache 모듈의 버전을 나타냅니다. 주어진 응답을 변환합니다. Google이 "X-" 없이 "Mod-Pagespeed"를 사용하고/하거나 IETF에 사용을 축복해 달라고 요청해야 한다고 정말로 제안하는 사람이 있습니까?

요약:
앱 내에서 사용자 정의 HTTP 헤더(때로는 쿠키에 대한 적절한 대안으로)를 사용하여 서버와 데이터를 주고받고 이러한 헤더가 명시적으로 애플리케이션 컨텍스트 외부에서 사용되도록 의도되지 않은 경우, "X-" 또는 "X-FOO-" 접두사로 이름 간격을 지정하는 것은 합리적이고 일반적인 규칙입니다.

cweekly

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 = <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비트 문자를 제외하는 것이 없습니다. 이는 명시적으로 옥텟으로 구성되며 제어 문자만 금지됩니다(CR 및 LF는 제어로 간주됨). 게다가, TEXT 생산에 대한 논평은 옥텟이 ISO-8859-1에 있는 것으로 해석되어야 하고 그 인코딩 외부의 문자를 표현하기 위한 인코딩 메커니즘이 있음을 암시합니다.

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

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

Tom Anderson

RFC6648 은 사용자 정의 헤더가 "표준화되거나, 공개되거나, 일반적으로 배포되거나 여러 구현에서 사용 가능해질 수" 있다고 가정할 것을 권장합니다. 따라서 "X-" 또는 유사한 구문을 접두사로 사용하지 않는 것이 좋습니다.

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

Edward Brey

추가 HTTP 헤더를 수정하거나 더 정확하게 추가 하는 것은 다른 것이 아니라면 훌륭한 코드 디버깅 도구입니다.

URL 요청이 리디렉션이나 이미지를 반환하면 디버그 코드의 결과를 임시로 기록할 html "페이지"가 없습니다. 적어도 브라우저에 표시되는 것은 아닙니다.

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

나는 정기적으로 X-fubar-somevar: 또는 X-testing-someresult:와 같은 추가 HTTP 헤더를 추가하여 테스트합니다. 그렇지 않으면 추적하기 매우 어려웠을 버그를 많이 발견했습니다.

g1smd

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

내가 말할 수 있는 한, 개인 헤더에 대한 지침은 없습니다. 의심스러운 경우 피하십시오. 또는 HTTP 확장 프레임워크( RFC 2774 )를 살펴보십시오.

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

Julian Reschke

출처 : http:www.stackoverflow.com/questions/3561381/custom-http-headers-naming-conventions