HTTP 헤더필드 리스트

List of HTTP header fields
HTTP
HTTP logo.svg
요구 방식
헤더 필드
응답 상태 코드
보안 접근 제어 방법
보안 취약성

HTTP 헤더필드는 모든 HTTP 요구 및 응답에 대해 클라이언트프로그램과 서버에서 송수신되는 문자열 목록입니다.이러한 헤더는 보통 최종 사용자에게는 보이지 않으며 서버 및 클라이언트애플리케이션에 의해서만 처리 또는 기록됩니다.접속을 통해 송수신되는 정보의 부호화 방법(Content-Encoding과 같이), 클라이언트의 세션 검증과 식별(브라우저 쿠키, IP 주소, 사용자 에이전트) 또는 익명성(VPN 또는 프록시 마스킹, 사용자 에이전트 스푸핑), 서버의 데이터 처리 방법(Do-Not-Track과 같이)을 정의합니다.다운로드 중인 문서의 공유 캐시에 상주한 시간).

일반 형식

HTTP 버전 1.x에서는 헤더필드는 요청 행(요구 HTTP 메시지의 경우) 또는 응답 행(응답 HTTP 메시지의 경우) 뒤에 전송됩니다.이 행은 메시지의 첫 번째 행입니다.헤더 필드는 콜론으로 구분된 클리어 텍스트 문자열 형식의 키와 값의 쌍으로, Carriage Return(CR; 캐리지 리턴) 및 Line Feed(LF; 줄바꿈) 문자 시퀀스로 끝납니다.헤더 섹션의 끝은 빈 필드 행으로 나타나며, 그 결과 2개의 연속된 CR-LF 쌍이 전송됩니다.과거에는 긴 줄을 여러 줄로 접을 수 있었습니다. 연속선은 다음 줄의 첫 번째 문자로 공백(SP) 또는 수평 탭(HT)이 있는 것으로 나타납니다.이 접기는 이제 [1]더 이상 사용되지 않습니다.

대신 HTTP[2]/2 및 HTTP/3는 바이너리 프로토콜을 사용합니다.여기서 헤더는 단일로 인코딩됩니다.HEADERS0 이상CONTINUATIONHPACK(HTTP/2) 또는 QPACK(HTTP/3)를 사용하는[3] 프레임으로, 양쪽 모두 효율적인 헤더 압축을 실현합니다.HTTP/1로부터의 요구 또는 응답 행도 콜론으로 시작하는 여러 의사 헤더필드로 대체되었습니다.:).

필드명

핵심 필드 세트는 Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회)에 의해 RFC 7230, 7231, 7232, 7233, 7234 및 7235로 표준화되어 있습니다.필드명, 헤더필드 및 잠정등록 저장소는 IANA에 의해 유지됩니다.각 응용 프로그램에 의해 추가 필드 이름과 허용 값을 정의할 수 있습니다.

헤더 필드명은 대소문자를 [4]구분하지 않습니다.이는 대소문자를 [5][6]구분하는HTTP 메서드명(GET, POST 등)과는 대조적입니다.

HTTP/2 에서는, 특정의 헤더 필드에 몇개의 제한이 있습니다(아래를 참조).

비표준 헤더필드는 일반적으로 필드 이름 앞에 다음과 같은 마크를 붙입니다.X-그러나 이 협약은 2012년 6월 비표준 분야가 [7]표준화되면서 불편을 겪었다는 이유로 폐지됐다.이전의 사용 제한Downgraded-2013년 [8]3월에 해제되었습니다.

필드 값

일부 필드에는 [9]사용자 에이전트, 서버, 경유 필드 등 소프트웨어가 무시할 수 있는 코멘트가 포함될 수 있습니다.

많은 필드 값에는 콘텐츠네고시에이션에서 [10]사용할 가중치를 지정하는 등호 기호로 구분된 품질(q) 키와 값의 쌍이 포함될 수 있습니다.예를 들어, 브라우저는 다음 q 값을 설정하여 독일어 또는 영어로 정보를 받아들이도록 지시할 수 있습니다.de보다 높은en다음과 같습니다.

Accept-Language: de; q=1.0, en; q=0.5

크기 제한

표준에서는 각 헤더필드 이름 또는 값의 크기 또는 필드 수에 제한이 없습니다.그러나 대부분의 서버, 클라이언트 및 프록시 소프트웨어는 실용적이고 보안적인 이유로 몇 가지 제한을 가합니다.예를 들어 Apache 2.3 서버는 기본적으로 각 필드의 크기를 8,190바이트로 제한하며 단일 요청에 [11]최대 100개의 헤더 필드를 포함할 수 있습니다.

요청 필드

표준 요청 필드

이름. 묘사 예 상황 표준.
A-IM 요구에 [12]대한 허용 가능한 인스턴스 조작. A-IM: feed 영구적인 RFC 3229
승낙하다 응답에 사용할 수 있는 미디어 유형입니다.컨텐츠의 네고시에이션을 참조해 주세요. Accept: text/html 영구적인 RFC 2616, 7231
Accept-Charset(승인 문자 집합) 허용 가능한 문자 집합입니다. Accept-Charset: utf-8 영구적인 RFC 2616
수용일시 적절한 버전입니다. Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT 잠정적인 RFC 7089
Accept-Encoding(승인 부호화) 허용 가능한 인코딩 목록입니다.「HTTP 압축」을 참조해 주세요. Accept-Encoding: gzip, deflate 영구적인 RFC 2616, 7231
수용 언어 응답에 사용할 수 있는 인간의 언어 목록입니다.컨텐츠의 네고시에이션을 참조해 주세요. Accept-Language: en-US 영구적인 RFC 2616, 4021, 7231
액세스 제어 요구 방식,
액세스 제어 요구 헤더[13]		 오리진과의 교차 오리진 리소스 공유 요청을 시작합니다(아래). Access-Control-Request-Method: GET 영속: 표준
허가 HTTP 인증용 인증 credential. Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 영구적인 RFC 2616, 7123, 7235
캐시 제어 요청-응답 체인의 모든 캐싱 메커니즘에서 따라야 하는 디렉티브를 지정하기 위해 사용됩니다. Cache-Control: no-cache 영구적인 RFC 2616, 7231, 7234
연결 현재 연결 및 홉 바이 홉 요청 [14]필드 목록 제어 옵션.

HTTP/[15]2와 함께 사용할 수 없습니다.

Connection: keep-alive

Connection: Upgrade

영구적인 RFC 2616, 7230
콘텐츠 부호화 데이터에 사용되는 인코딩 유형입니다.「HTTP 압축」을 참조해 주세요. Content-Encoding: gzip 영구적인 RFC 2616, 7231
콘텐츠 길이 요청 본문의 길이(8비트바이트)입니다. Content-Length: 348 영구적인 RFC 2616, 7230, 7231
콘텐츠 MD5 요청 본문 콘텐츠의 Base64 인코딩 바이너리 MD5 합계. Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== 구식[16] RFC 1544, 1864, 4021
Content-Type 요청 본문의 미디어 유형(POST 및 PUT 요청과 함께 사용됨). Content-Type: application/x-www-form-urlencoded 영구적인 RFC 2616, 4021, 7231
쿠키 서버에 의해 이전에 송신된HTTP cookieSet-Cookie（ ( ( ） 。 Cookie: $Version=1; Skin=new; 영속: 표준 RFC 2965, 6265
날짜. 메시지가 발송된 날짜와 시각(RFC 7231 Date/Time Formats에서 정의된 'HTTP-date' 형식). Date: Tue, 15 Nov 1994 08:12:31 GMT 영구적인 RFC 2616, 5322, 5536, 7231
기대하다 클라이언트에 의해 특정 서버 동작이 요구됨을 나타냅니다. Expect: 100-continue 영구적인 RFC 2616, 7231
전송 완료 HTTP [17]프록시를 통해 웹 서버에 연결하는 클라이언트의 원래 정보를 공개합니다. Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43 Forwarded: for=192.0.2.43, for=198.51.100.17 영구적인 RFC 7239
부터 요청을 하는 사용자의 전자 메일 주소입니다. From: user@example.com 영구적인 RFC 2616, 5322, 5536, 6854, 7231
주인 (가상 호스팅의 경우) 서버의 도메인 이름 및 서버가 수신하고 있는TCP 포트 번호포트가 요청된 서비스의 표준 포트인 경우 포트 번호를 생략할 수 있습니다.

HTTP/1.[18]1 이후 필수입니다. HTTP/2에서 직접 생성된 요청은 [19]사용하지 마십시오.

Host: en.wikipedia.org:8080

Host: en.wikipedia.org

HTTP2 설정 HTTP/1.1에서HTTP/2로의 업그레이드에 필요한 요구는 1개뿐입니다.HTTP2-Setting헤더 필드그HTTP2-Settingsheader 필드는 HTTP/2 접속을 제어하는 파라미터를 포함하는 접속 고유의 헤더필드입니다.[20][21]서버가 업그레이드 요구를 받아들이기 전에 제공됩니다. HTTP2-Settings: token64 영속: 표준
If-match(일치) 클라이언트 제공 엔티티가 서버상의 같은 엔티티와 일치하는 경우에만 액션을 수행합니다.이는 주로 사용자가 마지막으로 리소스를 업데이트한 후 변경되지 않은 경우에만 리소스를 업데이트하는 PUT 등의 메서드를 위한 것입니다. If-Match: "737060cd8c284d8af7ad3082f209582d" 영구적인 RFC 2616, 7323
If-Modified-이후 내용이 변경되지 않은 경우 304 Not Modified를 반환할 수 있습니다. If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 영구적인 RFC 2616, 7323
If-None-Match(If-None-Match) 내용이 변경되지 않은 경우 304 Not Modified를 반환할 수 있습니다(HTTP ETAG 참조). If-None-Match: "737060cd8c284d8af7ad3082f209582d" 영구적인 RFC 2616, 7232
If-Range(If-Range) 엔티티가 변경되지 않은 경우 누락된 부품을 보내거나, 그렇지 않은 경우 새 엔티티 전체를 보내십시오. If-Range: "737060cd8c284d8af7ad3082f209582d" 영구적인 RFC 2616, 7232, 7233
If-Unmodified-Since 이후 특정 시간 이후 엔티티가 변경되지 않은 경우에만 응답을 보냅니다. If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT 영구적인 RFC 2616, 7232
최대 포워드 프록시 또는 게이트웨이를 통해 메시지를 전송할 수 있는 횟수를 제한합니다. Max-Forwards: 10 영구적인 RFC 2616, 7231
원점[13] 크로스 오리진 자원 공유 요청을 시작합니다(Access-Control-* 응답 필드용 서버). Origin: http://www.example-social-network.com 영속: 표준 RFC 6454
프래그마 요청-응답 체인을 따라 다양한 영향을 미칠 수 있는 구현 고유의 필드입니다. Pragma: no-cache 영구적인 RFC 2616, 7234
선호하다 클라이언트가 요청을 처리하는 동안 특정 동작을 서버에 사용하도록 요청할 수 있습니다. Prefer: return=representation 영구적인 RFC 7240
프록시 인가 프록시에 연결하기 위한 인증 자격 정보입니다. Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 영구적인 RFC 2616, 7235
범위 엔티티의 일부만 요청합니다.바이트는 0부터 번호가 매겨집니다."바이트 서비스"를 참조하십시오. Range: bytes=500-999 영구적인 RFC 2616, 7233
참조자 [sic] 이것은, 현재 요구되고 있는 페이지에의 링크가 행해진 이전의 Web 페이지의 주소입니다.('referrer'라는 단어는 RFC 및 대부분의 실장에서는 철자가 잘못되어 표준 용어가 되어 올바른 용어로 간주되고 있습니다.) Referer: http://en.wikipedia.org/wiki/Main_Page 영구적인 RFC 2616, 7231
TE 사용자 에이전트가 받아들이는 전송 부호화: 응답 헤더필드와 같은 값 Transfer-Encoding 을 사용할 수 있습니다.또한 "chunked" 전송 방식과 관련된 "trailers" 값도 서버에 통지합니다.이 값은 크기가 제로인 마지막 청크 이후에 트레일러에서 추가 필드를 수신할 것으로 예상됩니다.

오직.trailers는 HTTP/[15]2에서 지원됩니다.

TE: trailers, deflate 영구적인 RFC 2616, 7230
트레일러 트레일러 일반 필드 값은 청크 전송 코딩으로 인코딩된 메시지의 트레일러에 지정된 헤더 필드 세트가 있음을 나타냅니다. Trailer: Max-Forwards 영구적인 RFC 2616, 7230
전송 부호화 엔티티를 사용자에게 안전하게 전송하기 위해 사용되는 인코딩 형식입니다.현재 정의된 메서드는 chunked, compress, deflate, gzip, identity입니다.

HTTP/[15]2와 함께 사용할 수 없습니다.

Transfer-Encoding: chunked 영구적인 RFC 2616, 7230
사용자 에이전트 사용자 에이전트의 사용자 에이전트 문자열. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0 영구적인 RFC 2616, 5536, 7231
개선하다 서버에 다른 프로토콜로 업그레이드하도록 요청하십시오.

HTTP/[15]2에서는 사용할 수 없습니다.

Upgrade: h2c, HTTPS/1.3, IRC/6.9, RTA/x11, websocket 영구적인 RFC 2616, 7230
경유 요청 전송에 사용된 프록시를 서버에 알립니다. Via: 1.0 fred, 1.1 example.com (Apache/1.1) 영구적인 RFC 2616, 7230
경고 엔티티 본체에 발생할 수 있는 문제에 대한 일반적인 경고입니다. Warning: 199 Miscellaneous warning 영구적인 RFC 2616, 7234

일반적인 비표준 요청 필드

필드명 묘사 예
Upgrade-Insecure-Requests[22] 클라이언트가 HTTPS보다 리다이렉트를 선호하며 처리할 수 있는 혼합 콘텐츠를 호스트하는 서버(HTTP -> HTTPS 이행 중)에 통지합니다.Content-Security-Policy: upgrade-insecure-requests

HTTP/2와[15] 함께 사용할 수 없습니다.

 Upgrade-Insecure-Requests: 1
X-Requested-With 주로 Ajax 요청을 식별하는 데 사용됩니다(대부분의 JavaScript 프레임워크는 이 필드를 다음과 같은 값으로 전송합니다).XMLHttpRequestWebView를 사용한[23] Android 앱 식별도 가능 X-Requested-With: XMLHttpRequest
DNT[24] 웹 응용 프로그램에 사용자 추적을 해제하도록 요청합니다.이것은 Firefox 4.0 베타 11 이후 Mozilla 버전의 X-Do-Not-Track 헤더 필드입니다.Safari 및 IE9도 이 [25]필드를 지원합니다.2011년 3월 7일 IETF에 [26]제안서 초안이 제출되었습니다.W3C Tracking Protection Working Group이 [27]사양을 작성하고 있습니다. DNT: 1(추적 사용 안 함)

DNT: 0(추적 비활성화 안 함)

X-Forwarded-For[28] HTTP 프록시 또는 로드 밸런서를 통해 웹 서버에 접속하는 클라이언트의 원래 IP 주소를 식별하기 위한 사실상의 표준입니다.Forwarded 헤더로 대체되었습니다. X-Forwarded-For: client1, proxy1, proxy2

X-Forwarded-For: 129.78.138.66, 129.78.64.103

X-Forwarded-Host(X[29] 전송 호스트) 에서 클라이언트에 의해 요청된 원래 호스트를 식별하기 위한 사실상의 표준HostHTTP 요청 헤더는 리버스 프록시(로드 밸런서)의 호스트 이름 및/또는 포트가 요청을 처리하는 원본 서버와 다를 수 있기 때문입니다.Forwarded 헤더로 대체되었습니다. X-Forwarded-Host: en.wikipedia.org:8080

X-Forwarded-Host: en.wikipedia.org

X-Forwarded-Proto[30] 역방향 프록시(또는 로드 밸런서)가 HTTPS인 경우에도 HTTP를 사용하여 웹 서버와 통신할 수 있으므로 HTTP 요청의 원래 프로토콜을 식별하기 위한 사실상의 표준입니다. Google 클라이언트와 대화하는 다른 형식의 헤더(X-ProxyUser-Ip)가 사용됩니다.Forwarded 헤더로 대체되었습니다. X-Forwarded-Proto: https
프론트[31] 엔드-Https Microsoft 응용 프로그램 및 로드밸런서가 사용하는 비표준 헤더 필드 Front-End-Https: on
X-Http-Method-Override[32] 요청으로 지정된 메서드(통상은 POST)를 헤더필드에 지정된 메서드(통상은 PUT 또는 DELETE)로 덮어쓰도록 웹 응용 프로그램에 요구합니다.이는 사용자 에이전트 또는 방화벽에 의해 PUT 또는 DELETE 메서드가 직접 전송되지 않을 때 사용할 수 있습니다(이는 소프트웨어 컴포넌트의 버그이며 수정해야 하거나 의도적인 설정이며, 이 경우 바이패스를 하는 것은 잘못된 것일 수 있습니다). X-HTTP-Method-Override: DELETE
X-ATT-DeviceId[33] 일반적으로 AT&T 디바이스의 User-Agent String에 있는 Make Model/Firmware를 쉽게 해석할 수 있습니다. X-Att-Deviceid: GT-P7320/P7320XXLPG
X-Wap[34] 프로파일 인터넷에 있는 XML 파일에 링크하여 현재 접속하고 있는 디바이스에 대한 자세한 설명과 상세 내용을 보여줍니다.오른쪽 예시는 AT&T 삼성 갤럭시S2용 XML 파일입니다. x-wap-profile: http://wap.samsungmobile.com/uaprof/SGH-I777.xml
프록시[35] 접속 HTTP 사양에 대한 오해로 구현되었습니다.초기 HTTP 버전 구현 오류 때문에 일반적입니다.표준 Connection 필드와 동일한 기능을 가지고 있습니다.

HTTP/[15]2와 함께 사용할 수 없습니다.

Proxy-Connection: keep-alive
X-UIDH[36][37][38] Verizon Wireless 고객을 식별하는 고유 ID의 서버 측 딥 패킷 삽입('perma-cookie' 또는 'supercookie'라고도 함) X-UIDH: ...
X-Csrf-Token[39] 사이트 간 요청 위조를 방지하기 위해 사용됩니다.대체 헤더 이름은 다음과 같습니다.X-CSRFToken[40] 그리고X-XSRF-TOKEN[41] X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
X-Request-ID,[stackoverflow2 1][42]

X[43][44] 상관 ID

 클라이언트와 서버간의 HTTP 요구를 관련짓습니다. X-Request-ID: f058ebd6-02f7-4d3f-942e-904344e8cde5
데이터[45] 저장 개발자는 Chrome, Opera 및 Yandex 브라우저에서 사용할 수 있는 Save-Data 클라이언트 힌트 요청 헤더를 사용하여 브라우저에서 데이터 저장 모드를 선택한 사용자에게 보다 가볍고 빠른 애플리케이션을 제공할 수 있습니다. Save-Data: on

[응답(Response)]필드

표준 응답 필드

필드명 묘사 예 상황 표준.
Accept-CH HTTP 클라이언트의 힌트 요구 Accept-CH: UA, Platform 실험적인 RFC 8942
액세스 제어 허가 발신지,
Access-Control-Allow-Credentials,
액세스 컨트롤 노출 헤더,
액세스 컨트롤 최대 경과시간,
액세스 제어 허가 방식,
액세스 제어 허가 헤더[13] 		원본 간 리소스 공유에 참여할 수 있는 웹 사이트 지정 Access-Control-Allow-Origin: * 영속: 표준 RFC 7480
수용[46] 패치 이 서버가 지원하는 패치 문서 형식을 지정합니다. Accept-Patch: text/example;charset=utf-8 영구적인 RFC 5789
수락 범위 이 서버가 바이트 서비스를 통해 지원하는 부분 콘텐츠 범위 유형 Accept-Ranges: bytes 영구적인 RFC 2616, 7233
나이 개체가 프록시 캐시에 있었던 기간(초) Age: 12 영구적인 RFC 2616, 7234
허락하다 지정된 리소스에 유효한 메서드입니다.405 메서드에 사용할 수 없습니다. Allow: GET, HEAD 영구적인 RFC 2616, 7231
Alt-Svc[47] 서버는 Alt-Svc 헤더(대체 서비스라는 의미)를 사용하여 리소스가 다른 네트워크 위치(호스트 또는 포트)에서도 액세스할 수 있는지 또는 다른 프로토콜을 사용하여 액세스할 수 있는지를 나타냅니다.

HTTP/2 를 사용하는 경우, 서버는 대신에 ALTSVC 프레임을 송신할 필요가 있습니다.[48]

 Alt-Svc: http/1.1="http2.example.com:8001"; ma=7200 영구적인
캐시 제어 서버에서 클라이언트로의 모든 캐싱 메커니즘이 이 개체를 캐시할 수 있는지 여부를 알려줍니다.초단위로 측정됩니다. Cache-Control: max-age=3600 영구적인 RFC 2616, 7231, 7234
연결 현재 연결 및 홉 바이 홉 응답 [14]필드 목록 제어 옵션.

HTTP/[15]2와 함께 사용할 수 없습니다.

Connection: close 영구적인 RFC 2616, 7230
콘텐츠[49] 폐기 이진 형식의 알려진 MIME 유형에 대해 "파일 다운로드" 대화상자를 표시하거나 동적 컨텐츠의 파일 이름을 제안할 수 있는 기회입니다.특수 문자의 따옴표는 필수입니다. Content-Disposition: attachment; filename="fname.ext" 영구적인 RFC 2616, 4021, 6266
콘텐츠 부호화 데이터에 사용되는 인코딩 유형입니다.「HTTP 압축」을 참조해 주세요. Content-Encoding: gzip 영구적인 RFC 2616, 7231
콘텐츠 언어 동봉된[50] 내용에 대한 대상 사용자의 자연어 또는 언어 Content-Language: da 영구적인 RFC 2616, 4021, 7231
콘텐츠 길이 응답 본문의 길이(8비트바이트) Content-Length: 348 영구적인 RFC 2616, 7230, 7231
콘텐츠 위치 반환된 데이터의 대체 위치 Content-Location: /index.htm 영구적인 RFC 2616, 4021, 7231
콘텐츠 MD5 응답 내용의 Base64 인코딩 바이너리 MD5 합계 Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== 구식[16] RFC 1544, 1864, 4021
콘텐츠 범위 본문 메시지에서 이 부분 메시지가 속한 위치 Content-Range: bytes 21010-47021/47022 영구적인 RFC 2616, 7233
Content-Type 이 콘텐츠의 MIME 유형 Content-Type: text/html; charset=utf-8 영구적인 RFC 2616, 4021, 7231
날짜. 메시지가 발송된 날짜 및 시간(RFC 7231에서 정의된 "HTTP-date" 형식) Date: Tue, 15 Nov 1994 08:12:31 GMT 영구적인 RFC 2616, 5322, 5536, 7231
델타 베이스 응답의 [12]델타 부호화 엔티티 태그를 지정합니다. Delta-Base: "abc" 영구적인 RFC 3229
ETAG 리소스 특정 버전의 식별자(대개 메시지 다이제스트) ETag: "737060cd8c284d8af7ad3082f209582d" 영구적인 RFC 2616, 7232
유효기간 응답이 오래된 것으로 간주될 때까지의 날짜/시간을 지정합니다(RFC 7231에서 정의된 「HTTP-date」형식). Expires: Thu, 01 Dec 1994 16:00:00 GMT 영속: 표준 RFC 2616, 4021, 5536, 7234
IM 응답에 [12]적용되는 인스턴스 조작. IM: feed 영구적인 RFC 3229
최종 수정일 요청된 개체의 마지막 수정 날짜(RFC 7231에서 정의된 "HTTP-date" 형식) Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT 영구적인 RFC 2616, 7232
링크 RFC 5988에서 정의되어 있는 다른 자원과의 유형화된 관계를 나타내기 위해 사용됩니다. Link: </feed>; rel="alternate"[52] 영구적인 RFC 5988
위치 리디렉션 또는 새 리소스가 생성된 경우 사용됩니다.
  • 예 1:Location: http://www.w3.org/pub/WWW/People.html
  • 예 2:Location: /pub/WWW/People.html
 영구적인 RFC 2068, 2616, 7231
P3P 이 필드는 다음 형식으로 P3P 정책을 설정합니다.P3P:CP="your_compact_policy"그러나 P3P는 [53]성공하지 못했고, 대부분의 브라우저는 완전히 구현되지 않았으며, 많은 웹 사이트가 가짜 정책 텍스트로 이 필드를 설정했으며, 이는 브라우저에 P3P 정책의 존재를 속이고 서드파티 쿠키에 대한 권한을 부여하기에 충분했습니다. P3P: CP="This is not a P3P policy! See https://en.wikipedia.org/wiki/Special:CentralAutoLogin/P3P for more info." 영구적인
프래그마 요청-응답 체인을 따라 다양한 영향을 미칠 수 있는 구현 고유의 필드입니다. Pragma: no-cache 영구적인 RFC 2616, 7234
프리퍼런스 적용 서버에 의해 승인되어 요청 처리에 적용되는 선호 토큰을 나타냅니다. Preference-Applied: return=representation 영구적인 RFC 7240
프록시 인증 프록시에 액세스하기 위한 인증을 요구합니다. Proxy-Authenticate: Basic 영구적인 RFC 2068, 2616, 7235
공개[54] 키 핀 HTTP 공개 키 피닝, 웹 사이트의 인증 TLS 인증서 해시를 알립니다. Public-Key-Pins: max-age=2592000; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; 영구적인 RFC 7469
재시도 후 엔티티를 일시적으로 사용할 수 없는 경우 클라이언트는 나중에 다시 시도하도록 지시됩니다.값은 지정된 기간(초단위) 또는 HTTP [55]날짜입니다.
  • 예 1:Retry-After: 120
  • 예 2:Retry-After: Fri, 07 Nov 2014 23:59:59 GMT

영구적인

 RFC 2616, 7231
서버 서버 이름 Server: Apache/2.4.1 (Unix) 영구적인 RFC 2068, 2616, 7231
HTTP 쿠키 Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 영속: 표준 RFC 6265
엄격한 트랜스포트 보안 HTTPS 전용 정책을 캐시하는 기간과 이것이 서브 도메인에 적용되는지 여부를 HTTP 클라이언트에 통지하는 HSTS 정책. Strict-Transport-Security: max-age=16070400; includeSubDomains 영속: 표준
트레일러 트레일러 일반 필드 값은 청크 전송 코딩으로 인코딩된 메시지의 트레일러에 지정된 헤더 필드 세트가 있음을 나타냅니다. Trailer: Max-Forwards 영구적인 RFC 2616, 7230
전송 부호화 엔티티를 사용자에게 안전하게 전송하기 위해 사용되는 인코딩 형식입니다.현재 정의된 메서드는 chunked, compress, deflate, gzip, identity입니다.

HTTP/[15]2와 함께 사용할 수 없습니다.

Transfer-Encoding: chunked 영구적인 RFC 2616, 7230
Tk Tracking Status 헤더, DNT(do-not-track)에 대한 응답으로 송신하도록 권장되는 값, 가능한 값:
"!" - 구축 중?" - 동적 "G" - 여러 당사자 "N"에 대한 게이트웨이 - "T" 추적 안 함 - "C" 추적 동의 "P" 추적 - 동의한 경우에만 추적 - DNT "U" 무시 - 업데이트됨
 Tk: ? 영구적인
개선하다 클라이언트에 다른 프로토콜로 업그레이드하도록 요청하십시오.

HTTP/2에서는[15] 사용할 수 없습니다.

 Upgrade: h2c, HTTPS/1.3, IRC/6.9, RTA/x11, websocket 영구적인 RFC 2616, 7230
다르다 오리진 서버에서 새 응답을 요청하는 대신 캐시된 응답을 사용할 수 있는지 여부를 결정하기 위해 향후 요청 헤더를 일치시키는 방법을 다운스트림 프록시에 지시합니다.
  • 예 1:Vary: *
  • 예 2:Vary: Accept-Language
 영구적인 RFC 2068, 2616, 7231
경유 응답이 송신된 프록시를 클라이언트에 통지합니다. Via: 1.0 fred, 1.1 example.com (Apache/1.1) 영구적인 RFC 2616, 7230
경고 엔티티 본체에 발생할 수 있는 문제에 대한 일반적인 경고입니다. Warning: 199 Miscellaneous warning 영구적인 RFC 2616, 7234
WWW 인증 요청된 엔티티에 액세스하기 위해 사용해야 하는 인증 방식을 나타냅니다. WWW-Authenticate: Basic 영구적인 RFC 2068, 2616, 7235
X[56] 프레임 옵션 클릭잭킹 보호:deny- 프레임 내 렌더링 없음,sameorigin- 원본이 일치하지 않으면 렌더링하지 않습니다.allow-from- 지정된 위치에서 허용,allowall- 비표준, 모든 위치에서 허용 X-Frame-Options: deny 구식[57]

일반적인 비표준 응답 필드

필드명 묘사 예
Content-Security-Policy,
X-Content-Security-Policy,
X-WebKit-CSP[58] 		콘텐츠 보안 정책 정의. X-WebKit-CSP: default-src 'self'
예상-CT[59] 인증서 투명성을 적용하도록 통지합니다. Expect-CT: max-age=604800, enforce, report-uri="https://example.example/report"
NEL[60] 네트워크 요청 로깅 설정에 사용됩니다. NEL: { "report_to": "name_of_reporting_group", "max_age": 12345, "include_subdomains": false, "success_fraction": 0.0, "failure_fraction": 1.0 }
권한[61] 정책 브라우저의 다른 기능 또는 API를 허용 또는 비활성화합니다. Permissions-Policy: fullscreen=(), camera=(), microphone=(), geolocation=(), interest-cohort=()[62]
리프레시 리디렉션 또는 새 리소스가 생성된 경우 사용됩니다.이 리프레시는 5초 후에 리다이렉트 됩니다.Netscape에 의해 도입되어 대부분의 웹 브라우저에서 지원되는 헤더 확장입니다.HTML[63] 표준으로 정의 Refresh: 5; url=http://www.w3.org/pub/WWW/People.html
보고처[64] 오리진에 대한 보고 끝점을 저장하도록 사용자 에이전트에 지시합니다. Report-To: { "group": "csp-endpoint", "max_age": 10886400, "endpoints": [ { "url": "https-url-of-site-which-collects-reports" } ] }
상황 HTTP 응답 상태를 지정하는 CGI 헤더필드통상의 HTTP 응답에서는, 대신에 RFC [65]7230 에서 정의되고 있는 개별의 「상태 라인」이 사용됩니다. Status: 200 OK
타이밍 허가 발신기지 그Timing-Allow-Originresponse header는 Resource Timing API 기능을 통해 취득된 Atribute 값을 표시할 수 있는 오리진을 지정합니다.이 값이 표시되지 않을 경우 발신기지 간 [66]제한으로 인해 0으로 보고됩니다. Timing-Allow-Origin: *

Timing-Allow-Origin: <origin>[, <origin>]*

X-콘텐츠-기간[67] Gecko 브라우저에서만 지원되는 오디오 또는 비디오 지속 시간(초) X-Content-Duration: 42.666
X-Content-Type-옵션[68] 유일하게 정의된 값인 "nosniff"는 Internet Explorer가 선언된 내용 유형에서 떨어진 응답을 MIME으로 탐지하는 것을 방지합니다.이는 [69]확장 버전을 다운로드할 때 Google Chrome에도 적용됩니다. X-Content-Type-Options: nosniff[70]
X-Powered-By[stackoverflow1 1] 기술을 지정합니다(예: ASP).웹 애플리케이션을 지원하는 NET, PHP, JBoss) (버전의 자세한 내용은 자주 참조)X-Runtime,X-Version, 또는X-AspNet-Version) X-Powered-By: PHP/5.4.0
X[71] 리다이렉트 기준 특정 리디렉션을 담당하는 구성 요소를 지정합니다. X-Redirect-By: WordPress
X-Redirect-By: Polylang
X-Request-ID, X-Correlation-ID[stackoverflow2 1] 클라이언트와 서버간의 HTTP 요구를 관련짓습니다. X-Request-ID: f058ebd6-02f7-4d3f-942e-904344e8cde5
X-UA[72] 호환 콘텐츠를 표시하는 데 사용할 기본 렌더링 엔진(종종 하위 호환성 모드)을 권장합니다.Internet Explorer에서 Chrome 프레임을 활성화하는 데도 사용됩니다.HTML 표준에서는IE=edge값이 [73]정의되어 있습니다. X-UA-Compatible: IE=edge
X-UA-Compatible: IE=EmulateIE7
X-UA-Compatible: Chrome=1
X-XSS-보호[74] 크로스 사이트 스크립팅(XSS) 필터 X-XSS-Protection: 1; mode=block

선택한 필드의 효과

캐싱 회피

웹 서버가 다음과 같이 응답하는 경우Cache-Control: no-cache그 후 웹 브라우저 또는 기타 캐싱 시스템(인증 프록시)은 처음에 발신측 서버에 체크하지 않고 후속 요구를 만족시키기 위해 응답을 사용할 수 없습니다(이 프로세스를 검증이라고 부릅니다).이 헤더 필드는 HTTP 버전 1.1의 일부이며 일부 캐시 및 브라우저에서는 무시됩니다.이것은, 다음의 설정에 의해서 시뮬레이트 할 수 있습니다.ExpiresHTTP 버전 1.0 헤더필드의 값을 응답 시간보다 이전 시간으로 설정합니다.캐시 없음은 브라우저 또는 프록시에 내용을 캐시할지 여부를 지시하지 않습니다.브라우저와 프록시에 캐시 콘텐츠를 사용하기 전에 서버에서 검증하도록 지시할 뿐입니다(이는 위에서 설명한 If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match 속성을 사용하여 이루어집니다).따라서 캐시 없음 값을 전송하면 브라우저 또는 프록시는 캐시 내용의 "신선도 기준"에 따라 캐시 내용을 사용하지 않도록 지시합니다.오래된 콘텐츠가 검증 없이 사용자에게 표시되지 않도록 하는 또 다른 일반적인 방법은 다음과 같습니다.Cache-Control: max-age=0이 명령어는 사용자 에이전트에 콘텐츠가 오래되었으므로 사용하기 전에 검증해야 함을 지시합니다.

헤더 필드Cache-Control: no-store는 브라우저 어플리케이션이 디스크에 쓰지 않도록(캐시하지 않도록) 지시하는 것을 목적으로 하고 있습니다.

리소스를 캐시하지 말라는 요청이 디스크에 기록되지 않는다는 보장은 없습니다.특히 HTTP/1.1 정의는 이력 스토어와 캐시를 구별합니다.사용자가 이전 페이지로 돌아가도 브라우저에 기록 저장소의 디스크에 저장된 페이지가 표시될 수 있습니다.이것은 사양에 따른 올바른 동작입니다.많은 사용자 에이전트는 프로토콜이 HTTP인지 HTTPS인지에 따라 기록 저장소 또는 캐시에서 페이지를 로드할 때 다른 동작을 보여줍니다.

그Cache-Control: no-cacheHTTP/1.1 헤더필드도 클라이언트의 요구에 사용하기 위한 것입니다.이는 브라우저가 서버와 중간 캐시에서 리소스의 새로운 버전을 요구함을 통지하는 수단입니다.그Pragma: no-cacheHTTP/1.0 사양에 정의되어 있는header 필드도 같은 목적을 가지고 있습니다.단, 요청 헤더에 대해서만 정의됩니다.응답 헤더의 의미는 [75]지정되지 않았습니다.동작Pragma: no-cache구현에 고유합니다.일부 사용자 에이전트는 응답 [76]시 이 필드에 주의를 기울이지만 HTTP/1.1 RFC에서는 이 동작에 의존하지 않도록 특별히 경고하고 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing". ietf.org. Retrieved July 23, 2014.
  2. ^ "Hypertext Transfer Protocol Version 2 (HTTP/2)". IETF. May 2015. Retrieved December 13, 2021.
  3. ^ "HPACK: Header Compression for HTTP/2". IETF. May 2015. Retrieved December 13, 2021.
  4. ^ RFC-7230 섹션 3.2
  5. ^ RFC-7210 섹션 3.1.1
  6. ^ RFC-7231 섹션 4.1
  7. ^ Internet Engineering Task Force (June 1, 2012). "RFC 6648". Retrieved November 12, 2012.
  8. ^ "Message Headers". Iana.org. June 11, 2014. Retrieved June 12, 2014.
  9. ^ "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing". itef.org. Retrieved July 24, 2014.
  10. ^ "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content". ietf.org. Retrieved July 24, 2014.
  11. ^ "core - Apache HTTP Server". Httpd.apache.org. Archived from the original on May 9, 2012. Retrieved March 13, 2012.
  12. ^ a b c RFC 3229. doi:10.17487/RFC3229.
  13. ^ a b c "Cross-Origin Resource Sharing". Retrieved July 24, 2017.
  14. ^ a b "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing". IETF. December 2021. Retrieved December 30, 2021.
  15. ^ a b c d e f g h i "Hypertext Transfer Protocol Version 2 (HTTP/2)". IETF. May 2015. Retrieved June 6, 2017.
  16. ^ a b "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content". Retrieved June 3, 2015.
  17. ^ "Forwarded HTTP Extension: Introduction". IETF. June 2014. Retrieved January 7, 2016.
  18. ^ "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing". IETF. June 2014. Retrieved July 24, 2014.
  19. ^ "Hypertext Transfer Protocol Version 2 (HTTP/2)". IETF. May 2015. Retrieved June 6, 2017.
  20. ^ "Message Headers". www.iana.org. Retrieved November 26, 2018.
  21. ^ "Hypertext Transfer Protocol Version 2 (HTTP/2)". httpwg.org. May 30, 2015. Retrieved February 22, 2019.
  22. ^ "Upgrade Insecure Requests - W3C Candidate Recommendation". W3C. October 8, 2015. Retrieved January 14, 2016.
  23. ^ "The "X-Requested-With" Header – Stoutner".
  24. ^ "Try out the "Do Not Track" HTTP header". Retrieved January 31, 2011.
  25. ^ "Web Tracking Protection: Minimum Standards and Opportunities to Innovate". Retrieved March 24, 2011.
  26. ^ IETF 추적 안 함: 유니버설 서드파티 웹 추적 옵션2011년 3월 7일
  27. ^ W3C Tracking Preference Expression (DNT), 2012년 1월 26일
  28. ^ Amos Jeffries (July 2, 2010). "SquidFaq/ConfiguringSquid - Squid Web Proxy Wiki". Retrieved September 10, 2009.
  29. ^ The Apache Software Foundation. "mod_proxy - Apache HTTP Server Version 2.2". Retrieved November 12, 2014.
  30. ^ Dave Steinberg (April 10, 2007). "How do I adjust my SSL site to work with GeekISP's loadbalancer?". Retrieved September 30, 2010.
  31. ^ "Helping to Secure Communication: Client to Front-End Server". July 27, 2006. Retrieved April 23, 2012.
  32. ^ "OpenSocial Core API Server Specification 2.5.1". Retrieved October 8, 2014.
  33. ^ "ATT Device ID". Archived from the original on February 16, 2012. Retrieved January 14, 2012.
  34. ^ "WAP Profile". Retrieved January 14, 2012.
  35. ^ de Boyne Pollard, Jonathan (2007). "The Proxy-Connection: header is a mistake in how some web browsers use HTTP". Retrieved January 16, 2018.
  36. ^ "Verizon Injecting Perma-Cookies to Track Mobile Customers, Bypassing Privacy Controls". Electronic Frontier Foundation. Retrieved January 19, 2014.
  37. ^ "Checking known AT&T, Verizon, Sprint, Bell Canada & Vodacom Unique Identifier beacons". Retrieved January 19, 2014.
  38. ^ Craig Timberg. "Verizon, AT&T tracking their users with 'supercookies'". The Washington Post. Retrieved January 19, 2014.
  39. ^ "SAP Cross-Site Request Forgery Protection". SAP SE. Retrieved January 20, 2015.
  40. ^ "Django Cross Site Request Forgery protection". Django (web framework). Archived from the original on January 20, 2015. Retrieved January 20, 2015.
  41. ^ "Angular Cross Site Request Forgery (XSRF) Protection". AngularJS. Retrieved January 20, 2015.
  42. ^ "HTTP Request IDs". devcenter.heroku.com. Retrieved March 22, 2022.
  43. ^ "The Value of Correlation IDs". Rapid7 Blog. December 23, 2016. Retrieved April 13, 2018.
  44. ^ Hilton, Peter. "Correlation IDs for microservices architectures - Peter Hilton". hilton.org.uk. Retrieved April 13, 2018.
  45. ^ "Save Data API Living Document Draft Community Group Report 2.1.1. Save-Data Request Header Field". Web Platform Incubator Community Group. June 30, 2020. Retrieved March 5, 2021.
  46. ^ "RFC 5789". Retrieved December 24, 2014.
  47. ^ "HTTP Alternative Services". IETF. April 2016. Retrieved April 19, 2016.
  48. ^ "HTTP Alternative Services, section 3". IETF. April 2016. Retrieved June 8, 2017.
  49. ^ "RFC 6266". Retrieved March 13, 2015.
  50. ^ "RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content". Tools.ietf.org. Retrieved December 11, 2017.
  51. ^ "RFC7231 Compliant HTTP Date Headers".
  52. ^ 링크 rel="links" HTTP 헤더 Retrived: 2012-02-09로 응답하여 URL의 정식 버전을 나타냅니다.
  53. ^ W3C P3P 작업 일시정지
  54. ^ "Public Key Pinning Extension for HTTP". IETF. Retrieved April 17, 2015.
  55. ^ "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content". Retrieved July 24, 2014.
  56. ^ "HTTP Header Field X-Frame-Options". IETF. 2013. Retrieved June 12, 2014.
  57. ^ "Content Security Policy Level 2". Retrieved August 2, 2014.
  58. ^ "Content Security Policy". W3C. 2012. Retrieved April 28, 2017.
  59. ^ "Expect-CT". Mozilla Developer Network. Retrieved July 23, 2021.
  60. ^ "NEL". Mozilla Developer Network. 2021. Retrieved May 18, 2021.
  61. ^ "Permissions Policy". W3C. 2020. Retrieved May 1, 2021.
  62. ^ "Am I FLoCed?". EFF. 2021. Retrieved May 1, 2021.
  63. ^ "Define the HTTP Refresh header by annevk · Pull Request #2892 · whatwg/html". GitHub. August 9, 2017. Retrieved April 17, 2021.
  64. ^ "CSP: report-to". Mozilla Developer Network. 2021. Retrieved May 18, 2021.
  65. ^ RFC 7230: Hypertext Transfer Protocol (HTTP/1.1):메시지 구문 및 라우팅
  66. ^ "Timing-Allow-Origin". Mozilla Developer Network. Retrieved January 25, 2018.
  67. ^ "Configuring servers for Ogg media". May 26, 2014. Retrieved January 3, 2015.
  68. ^ Eric Lawrence (September 3, 2008). "IE8 Security Part VI: Beta 2 Update". Retrieved September 28, 2010.
  69. ^ "Hosting - Google Chrome Extensions - Google Code". Retrieved June 14, 2012.
  70. ^ van Kesteren, Anne (August 26, 2016). "Fetch standard". WHATWG. Archived from the original on August 26, 2016. Retrieved August 26, 2016.
  71. ^ "X-Redirect-By HTTP response header". Retrieved May 29, 2021.
  72. ^ "Defining Document Compatibility: Specifying Document Compatibility Modes". April 1, 2011. Retrieved January 24, 2012.
  73. ^ "HTML Living Standard 4.2.5.3 Pragma directives, X-UA-Compatible state". WHATWG. March 12, 2021. Retrieved March 14, 2021. For meta elements with an http-equiv attribute in the X-UA-Compatible state, the content attribute must have a value that is an ASCII case-insensitive match for the string"IE=edge".
  74. ^ Eric Lawrence (July 2, 2008). "IE8 Security Part IV: The XSS Filter". Retrieved September 30, 2010.
  75. ^ "Hypertext Transfer Protocol (HTTP/1.1): Caching". ietf.org. Retrieved July 24, 2014.
  76. ^ "How to prevent caching in Internet Explorer". Microsoft. September 22, 2011. Retrieved April 15, 2015.

이 편집 시점에서는, 이 기사는, 다음의 컨텐츠를 사용하고 있습니다."X-REQUEST-ID http 헤더란?"Stephan Kögl에 의해 스택 익스체인지에서 작성되었으며, Creative Commons Attribution-Share Alike 3.0 Unported License에서는 재사용할 수 있지만 GFDL에서는 재사용할 수 없습니다.모든 관련 조건을 따라야 합니다.

  1. ^ a b "What is the X-REQUEST-ID http header?". Retrieved March 20, 2022.

이 편집 시점에서는, 이 기사는, 다음의 컨텐츠를 사용하고 있습니다.ASP가 왜?NET 프레임워크에 'X-Powered-By:ASP.NET의 HTTP 헤더에 대한 응답?"스택 익스체인지에서 Adrian Grigore에 의해 작성되었으며, Creative Commons Attribution-Share Alike 3.0 Unported License에서는 재사용이 허용되지만 GFDL에서는 허용되지 않습니다.모든 관련 조건을 따라야 합니다.

  1. ^ "Why does ASP.NET framework add the 'X-Powered-By:ASP.NET' HTTP Header in responses? - Stack Overflow". Retrieved March 20, 2022.

외부 링크