HTTP 색인

Found 126 pages:

#	Page	Tags and summary
1	HTTP	CORS, HTTP, Reference, TCP/IP, Web, l10n:priority
		하이퍼텍스트 전송 프로토콜(HTTP)은 HTML과 같은 하이퍼미디어 문서를 전송하기위한 애플리케이션 레이어 프로토콜입니다. 웹 브라우저와 웹 서버간의 커뮤니케이션을위해 디자인되었지만, 다른 목적으로도 사용될 수 있습니다. HTTP는 클라이언트가 요청을 생성하기 위한 연결을 연다음 응답을 받을때 까지 대기하는 전통적인 클라이언트-서버 모델을 따릅니다. HTTP는 무상태 프로토콜이며, 이는 서버가 두 요청간에 어떠한 데이터(상태)도 유지하지 않음을 의미합니다. 일반적으로 안정적인 전송 레이어로 UDP와 달리 메세지를 잃지 않는 프로토콜인 TCP/IP 레이어를 기반으로 사용 합니다. RUDP — 안정적인 업데이트인 UDP의 적합한 대안 입니다.
2	HTTP 인증
		HTTP는 액세스 제어와 인증을 위한 프레임워크를 제공합니다. 가장 일반적인 인증 방식은 "Basic" 인증 방식입니다. 이 페이지에서는 일반적인 HTTP 인증 프레임워크를 소개하고 서버에 HTTP의 Basic 인증 방식으로 접근을 제한하는 것을 보여 줍니다.
3	HTTP 기본	HTTP, NeedsTranslation, Overview, TopicStub
		HTTP는 상당히 확장 가능한 프로토콜입니다. 자원과 URI의 개념, 메시지의 단순한 구조, 통신 흐름을 위한 클라이언트-서버 구조와 같은 몇 가지 기본 개념에 의존합니다. 이러한 기본 개념을 토대로, 새로운 HTTP 메서드나 헤더의 생성을 통해 새로운 기능과 새로운 의미를 더하는 수많은 확장들이 수년간 생겨났습니다.
4	www와 비-www URL 중에서 선택하기
		웹 사이트 소유자들이 반복해서 하게 되는 질문은 비-www 혹은 www URL 중 무엇을 선택해야 하는가입니다. 이 페이지는 그에 대해 최선의 결론을 내기 위한 조언을 제공합니다.
5	Data URIs
		Data URIs, 즉 data: 스킴이 접두어로 붙은 URL은 컨텐츠 작성자가 작은 파일을 문서 내에 인라인으로 임베드할 수 있도록 해줍니다.
6	HTTP의 진화	HTTP, HTTP 역사, 가이드
		HTTP는 월드 와이드 웹에 내재된 프로토콜입니다. Tim Berners-Lee에 의해 1989년부터 1991년에 발명된 HTTP는, 본래의 단순함의 대부분을 지키면서 확장성 위에서 만들어지도록, 많은 수정을 거쳐왔습니다. HTTP는 의사-신뢰도가 있는 실험실 환경에서 파일을 교환하는 프로토콜에서 높은 수준의 분석과 3D 내에서 이미지와 비디오를 실어나르는 현대 인터넷 정글로 진화해 왔습니다.
7	웹 리소스 식별
		HTTP 요청 대상을 "리소스"라고 부르는데, 그에 대한 본질을 이 이상으로 정의할 수 없습니다; 그것은 문서, 사진 또는 다른 어떤 것이든 될 수 있습니다. 각 리소스는 리소스 식별을 위해 HTTP 전체에서 사용되는 Uniform Resource Identifier (URI)에 의해 식별됩니다.
8	MIME 타입
		MIME 타입이란 클라이언트에게 전송된 문서의 다양성을 알려주기 위한 메커니즘입니다: 웹에서 파일의 확장자는 별  의미가 없습니다. 그러므로, 각 문서와 함께 올바른 MIME 타입을 전송하도록, 서버가 정확히 설정하는 것이 중요합니다. 브라우저들은 리소스를 내려받았을 때 해야 할 기본 동작이 무엇인지를 결정하기 위해 대게 MIME 타입을 사용합니다.
9	MIME 타입의 전체 목록
		다음은 일반적인 확장자로 정렬된, 문서 타입과 관련된 MIME 타입의 포괄적인 목록입니다.
10	사용자 에이전트를 이용한 브라우저 감지	Compatibility, HTTP, Web Development
		보통 브라우저마다 다른 웹 페이지 또는 서비스를 제공하는 것은 나쁜 생각입니다. 웹은 사용자가 어떤 브라우저나 디바이스를 사용하고 있는지 개의치 않고 모두에게 접근성이 용이해야 하기 때문입니다. 따라서 특정 브라우저를 타겟으로 개발하는 것보다 가용적인 기능들 (예를 들어 Web API 등)을 이용하여 당신의 웹 사이트를 개선하는 것을 추천합니다.
11	HTTP caching	HTTP, 가이드, 캐싱
		웹 사이트와 애플리케이션의 성능은 이전에 가져온 리소스들을 재사용함으로써 현저하게 향상될 수 있습니다. 웹 캐시는 레이턴시와 네트워크 트래픽을 줄여줌으로써 리소스를 보여주는 데에 필요한 시간을 줄여줍니다. HTTP 캐싱을 활용하면 웹 사이트가 좀 더 빠르게 반응하도록 만들 수 있습니다.
12	HTTP에서의 압축
		압축은 웹 사이트의 성능을 높이는 중요한 방법입니다. 어떤 문서에 대해, 70%가 넘는 사이즈 축소는 필요로 하는 대역폭 용량을 낮춰줍니다. 수년간, 알고리즘은 점점 더 효율적으로 변해왔고, 클라이언트와 서버에 의해 새로운 것들이 지원되고 있습니다.
13	HTTP 조건부 요청
		영향을 받는 리소스들을 검사기 값을 이용해 비교함으로써, HTTP는, 성공인 경우라도, 요청의 결과가 변경될 수 있는 조건부 요청의 컨셉을 가지고 있습니다. 그런 요청들은 캐시 컨텐츠와 쓸모없는 컨트롤 회피를 검증하고, 다운로드를 이어서 하거나 서버 상의 문서를 업로드 또는 수정할 때 수정된 내용을 잃지 않도록 할 때처럼, 문서의 무결성을 확증하는데 유용할 수 있습니다.
14	HTTP/1.x의 커넥션 관리
		커넥션 관리는 HTTP의 주요 주제입니다: 대규모로 커넥션을 열고 유지하는 것은 웹 사이트 혹은 웹 애플리케이션의 성능에 많은 영향을 줍니다. HTTP/1.x에는 몇 가지 모델이 존재합니다: 단기 커넥션, 영속적인 커넥션, 그리고 HTTP 파이프라이닝.
15	Content negotiation
		HTTP에서, 컨텐츠 협상이란 동일한 URI에서 리소스의 서로 다른 버전을 서브하기 위해 사용되는 메커니즘으로, 사용자 에이전트가 사용자에게 제일 잘 맞는 것이 무엇인지(예를 들어, 문서의 언어, 이미지 포맷 혹은 컨텐츠 인코딩에 있어 어떤 것이 적절한지)를 명시할 수 있습니다.
16	HTTP 쿠키
		HTTP 쿠키(웹 쿠키, 브라우저 쿠키)는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각입니다. 브라우저는 그 데이터 조각들을 저장해 놓았다가, 동일한 서버에 재 요청 시 저장된 데이터를 함께 전송합니다. 쿠키는 두 요청이 동일한 브라우저에서 들어왔는지 아닌지를 판단할 때 주로 사용합니다. 이를 이용하면 사용자의 로그인 상태를 유지할 수 있습니다. 상태가 없는(stateless) HTTP 프로토콜에서 상태 정보를 기억시켜주기 때문입니다.
17	교차 출처 리소스 공유 (CORS)	CORS, HTTP, Same-origin policy, Security, l10n:priority, 교차 출처, 동일 출처
		교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 origin에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행합니다.
18	CORS errors	CORS, Errors, HTTP, HTTPS, Messages, NeedsTranslation, Same-origin, Security, TopicStub, console, troubleshooting
		Cross-Origin Resource Sharing (CORS) is a standard that allows a server to relax the same-origin policy. This is used to explicitly allow some cross-origin requests while rejecting others.
19	Reason: CORS request did not succeed
		네트워크 또는 프로토콜 수준에서 HTTP 연결이 실패했기 때문에 CORS를 사용하는  HTTP 요청이 실패했습니다. 이 에러는 근본적인 네트워크 에러이거나 그에 준하는 에러로 CORS와 직접적인 연관이 있는 것은 아닙니다.
20	Reason: CORS request not HTTP	CORS, CORSRequestNotHttp, HTTP, HTTPS, 메시지, 문제해결, 보안, 에러, 이유, 콘솔, 크로스 오리진
		CORS 요청은 오직 HTTPS URL 스키마만을 사용할 수 있지만 요청에 의해 지정된 URL은 다른 타입이다. 이는 URL이 file:/// URL을 사용해 로컬 파일을 지정할 경우 종종 발생한다.
21	HTTP 헤더	HTTP, HTTP 헤더, 개요, 네트워킹, 레퍼런스
		HTTP 헤더는 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해줍니다. HTTP 헤더는 대소문자를 구분하지 않는 이름과 콜론 ':' 다음에 오는 값(줄 바꿈 없이)으로 이루어져있습니다. 값 앞에 붙은 빈 문자열은 무시됩니다.
22	Accept-Charset
		Accept-Charset 요청 HTTP 헤더는 클라이언트가 이해할 수 있는 캐릭터셋이 무엇인지를 알려줍니다. 컨텐츠 협상을 사용하여, 서버는 제안된 것 중 하나를 선택하고, 사용하며 Content-Type 응답 헤더를 통해 선택된 캐릭터셋을 클라이언트에게 알려줍니다. 브라우저들은 각각의 컨텐츠 타입에 대한 기본 값이 일반적으로 정확하고 그것을 전송하는 것이 더 쉽게 행적을 남기게 될 가능성이 있으므로 이 헤더를 설정하지 않습니다.
23	Accept-Encoding
		Accept-Encoding 요청 HTTP 헤더는, 보통 압축 알고리즘인, 클라이언트가 이해 가능한 컨텐츠 인코딩이 무엇인지를 알려줍니다. 컨텐츠 협상을 사용하여, 서버는 제안된 내용 중 하나를 선택하고 사용하며 Content-Encoding 응답 헤더를 이용해 선택된 것을 클라이언트에게  알려줍니다.
24	Accept-Language
		Accept-Language 요청 HTTP 헤더는 어떤 언어를 클라이언트가 이해할 수 있는지, 그리고 지역 설정 중 어떤 것이 더 선호되는지를 알려줍니다. (여기서 언어란 프로그래밍 언어가 아니라 영어같은 자연 언어를 의미합니다.) 컨텐츠 협상을 사용하여, 서버는 제안 중 하나를 선택한 뒤, 그것을 사용하고 Content-Language 응답 헤더와 함께 선택된 내용을 클라이언트에게 알려줍니다. 브라우저는 사용자 인터페이스 언어에 따라 해당 헤더에 적절한 값을 설정하며 사용자가 사용자 인터페이스 언어를 변경한 경우조차도, 헤더의 값이 변경되는 일은 거의 없습니다(그리고 그런 일이 일어나게 되면 흔적이 남으므로 눈살을 찌프리게 됩니다).
25	Accept-Ranges
		Accept-Ranges 응답 HTTP 헤더는 부분 요청의 지원을 알리기 위해 서버에 의해 사용되는 표식입니다. 이 필드의 값은 범위를 정의하기 위해 사용될 수 있는 단위를 가리킵니다.
26	Accept
		Accept 요청 HTTP 헤더는 MIME 타입으로 표현되는, 클라이언트가 이해 가능한 컨텐츠 타입이 무엇인지를 알려줍니다. 컨텐츠 협상을 이용해, 서버는 제안 중 하나를 선택하고 사용하며 Content-Type 응답 헤더로 클라이언트에게 선택된 타입을 알려줍니다. 브라우저는 요청이 이루어진 컨텍스트에 따라 해당 헤더에 대해 적당한 값들을 설정합니다: CSS 스타일시트를 불러오게 되면, 이미지, 비디오 혹은 스크립트를 불러올 때와 다른 값이 요청에 대해 설정됩니다.
27	Access-Control-Allow-Credentials
		응답헤더 Access-Control-Allow-Credentials 는  요청의 자격증명 모드(Request.credentials)가 "include" 일때,   브라우저들이 응답을 프로트엔드 자바스트립트 코드에 노출할지에 대해 알려줍니다.
28	Access-Control-Allow-Headers	CORS, HTTP, Reference, 헤더
		Access-Control-Allow-Headers 는 Access-Control-Request-Headers를 포함하는 preflight request의 응답에 사용되는 헤더로, 실제 요청때 사용할 수 있는 HTTP 헤더의 목록을 나열합니다.
29	Access-Control-Allow-Origin
		Access-Control-Allow-Origin 응답 헤더는 이 응답이 주어진 origin으로부터의 요청 코드와 공유될 수 있는지를 나타냅니다.
30	Access-Control-Request-Headers	CORS, HTTP, Reference, header
		요청 헤더 Access-Control-Request-Headers는 실제 요청이 만들어질 때 클라이언트가 보낼 수도 있는 HTTP headers를 서버에게 알리기 위해 브라우저가 preflight request를 발급(issue)할 때 사용됩니다.
31	Access-Control-Request-Method	CORS, HTTP, Reference, header
		요청 헤더 Access-Control-Request-Method는 실제 요청이 만들어질 때 클라이언트가 보낼 수도 있는 HTTP headers를 서버에게 알리기 위해 브라우저가 preflight request를 발급(issue)할 때 사용됩니다. 사전 요청(preflight request)은 항상 OPTIONS이며 실제 요청과 동일한 메소드를 사용하지 않으므로 이 헤더가 필요합니다.
32	Age
		Age 헤더는 객체가 프록시 캐시 내에 머무는 초단위의 시간을 가집니다.
33	Allow	Entity header, HTTP, HTTP Header, Reference, header
		Allow 헤더는 리소스가 지원하는 메소드 집합을 나열합니다.
34	Authorization	HTTP, HTTP 헤더, 요청 헤더, 참고자료, 헤더
		HTTP Authorization 요청 헤더는 서버의 사용자 에이전트임을 증명하는 자격을 포함하여, 보통 서버에서 401 Unauthorized 상태를 WWW-Authenticate 헤더로 알려준 이후에 나옵니다.
35	Cache-Control
		Cache-Control 일반 헤더 필드는 요청과 응답 내의 캐싱 메커니즘을 위한 디렉티브를 정하기 위해 사용됩니다. 캐싱 디렉티브는 단방향성이며, 이는 요청 내에 주어진 디렉티브가 응답 내에 주어진 디렉티브와 동일하다는 것을 뜻하지는 않는다는 것을 의미합니다.
36	Connection	HTTP, 웹, 참조, 헤더
		Connection 일반 헤더는 현재의 전송이 완료된 후 네트워크 접속을 유지할지 말지를 제어합니다. 만약 전송된 값이 keep-alive면, 연결은 지속되고 끊기지 않으며, 동일한 서버에 대한 후속 요청을 수행할 수 있습니다.
37	Content-Disposition
		multipart/form-data 본문에서의 Content-Disposition 일반 헤더는 multipart의 하위파트에서 활용될 수 있는데, 이 때 이 헤더는 multipart 본문 내의 필드에 대한 정보를 제공합니다. multipart의 하위파트는 Content-Type 헤더에 정의된 boundary 구분자에 의해 구분되며, Content-Disposition 헤더를 multipart 자체에 사용하는 것은 아무런 효과를 발휘하지 못합니다.
38	Content-Encoding
		Content-Encoding 개체 헤더는 미디어 타입을 압축하기 위해 사용됩니다. 이 헤더가 존재하면, 그 값은 개체 본문에 어떤 추가적인 컨텐츠 인코딩이 적용될지를 나타냅니다. 그것은 Content-Type 헤더에 의해 참조되는 미디어 타입을 얻도록 디코드하는 방법을 클라이언트가 알게 해줍니다.
39	Content-Language
		Content-Language entity header는 청중을 위한 언어를 설명하기 위해 사용되는데, 사용자가 선호하는 언어에 따라 사용자를 구분하도록 해줍니다.
40	Content-Length
		Content-Length 개체 헤더는 수신자에게 보내지는, 바이트 단위를 가지는 개체 본문의 크기를 나타냅니다.
41	Content-Location
		Content-Location 헤더는 반환된 데이터에 대한 대체 위치을 가르킵니다. 주된 유스케이스는 컨텐츠 협상의 결과로써 전달되는 리소스의 URL을 가르키는 것입니다.
42	Content-Range	HTTP, HTTP 헤더, 응답 헤더, 참고자료, 헤더
		Content-Range HTTP 응답 헤더는 전체 바디 메시지에 속한 부분 메시지의 위치를 알려줍니다.
43	Content-Security-Policy	CSP, HTTP, Reference, Security, header
		The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (XSS).
44	CSP: default-src
		HTTP Content-Security-Policy (CSP) default-src 구문은 다른  CSP 구문이 정의되지 않았을때 이를 대체하는 용도로 사용됩니다.  as a fallback for the other CSP fetch directive. 다음과 같은 구문이 없는 경우,  default-src 구문을 찾아서 사용합니다:
45	CSP: img-src
		The HTTP Content-Security-Policy: img-src 지시어는 이미지 및 파비콘에 대하여 유효한 출처를 지정합니다.
46	report-to
47	CSP: script-src
		HTTP Content-Security-Policy (CSP) script-src 는 자바스크립트트에 대한 검증된 출처를 지정합니다. 여기에는 script 요소에서 직접 호출한 URL뿐만 아니라,  인라인 스크립트  이벤트 핸들러(onclick) 및 스크립트를 실행할 수 있는  XSLT stylesheets 가 포함됩니다.
48	Content-Type
		Content-Type 개체 헤더는 리소스의 MIME type을 나타내기 위해 사용됩니다.
49	Cookie
		Cookie HTTP 요청 헤더는 Set-Cookie 헤더와 함께 서버에 의해 이전에 전송되어 저장된 HTTP cookies를 포함합니다.
50	Date
		Date 일반 HTTP 헤더는 메시지가 만들어진 날짜와 시간을 포함합니다.
51	DNT
		DNT (Do Not Track) 요청 헤더는 사용자의 트래킹 선호 설정을 가르킵니다. 이는 개인화 컨텐츠가 아닌 사생활 정보를 더 It lets users indicate whether would prefer privacy rather than personalized content.
52	ETag
		ETag HTTP 응답 헤더는 특정 버전의 리소스를 식별하는 식별자입니다. 웹 서버가 내용을 확인하고 변하지 않았으면, 웹 서버로 full 요청을 보내지 않기 때문에, 캐쉬가 더 효율적이게 되고, 대역폭도 아낄 수 있습니다. 허나, 만약 내용이 변경되었다면, "mid-air collisions" 이라는 리소스 간의 동시 다발적 수정 및 덮어쓰기 현상을 막는데 유용하게 사용됩니다.
53	Expect
		Expect HTTP 요청 헤더는 요청을 적절하게 처리하기 위해 서버가 반환할 기대값을 나타냅니다.
54	Expires
		Expires 헤더는 응답이 더 이상 신선하지 않다고 판단할 날짜/시간을 포함합니다.
55	Forwarded	HTTP, HTTP 헤더, 요청 헤더, 참고자료, 헤더
		Forwarded 헤더는 클라이언트에서 접하고 있는 프록시 서버들이 요청에 대한 연결에 연관되어 있는 상황에서 해당 연결이 변경되거나 잃어버리게 되었을 때, 해당되는 정보를 가지고 있습니다.
56	From
		From 요청 헤더는 요청한 사용자 에이전트를 제어하는 인간 사용자의 인터넷 이메일을 포함합니다.
57	Host
		Host 요청 헤더는 (가상 호스팅을 위해) 서버의 도메인명과 서버가 리스닝하는 (부가적인) TCP 포트를 특정합니다.
58	If-Modified-Since
		If-Modified-Since HTTP 요청 헤더는 조건부 요청으로 서버는 지정된 날짜 이후 수정 된 경우에 200  과 함께 요청된 리소스를 돌려 줍니다. 만약 수정되지 않는 리소스에 대한 요청시, 리소스 없이 304  응답을 하게 됩니다. 이전 요청의 Last-Modified 응답 헤더는 마지막으로 수정 한 날짜를 포함합니다.If-Modified-Since는 If-Unmodified-Since 와는 다르게 GET 또는 HEAD 에서만 쓸수 있습니다.
59	If-Range	HTTP, HTTP 헤더, 범위 요청, 요청 헤더, 조건 요청, 참고자료
		If-Range HTTP 요청 헤더는 범위 요청을 조건적으로 만듭니다: 만약 조건이 만족된다면, 범위 요청은 처리되어 서버에서 206 Partial Content 응답을 적절한 바디를 포함하여 보낼 것입니다. 만약 조건을 만족하지 못한다면, 200 OK 상태 코드가 전체 리소스와 함께 돌아올 것입니다.
60	Keep-Alive
		Keep-Alive 일반 헤더는 송신자가 연결에 대한 타임아웃과 요청 최대 개수를 어떻게 정했는지에 대해 알려줍니다.
61	Last-Modified	HTTP, HTTP 헤더, 응답 헤더, 참고자료
		Last-Modified 응답은 HTTP 헤더에 서버가 알고있는 가장 마지막 수정된 날짜와 시각을 담고 있습니다. 이는 저장된 리소스가 이전과 같은지 유효성 검사자로 사용됩니다. ETag 헤더보다는 덜 정확하지만, 이는 대비책으로 사용됩니다. 조건 요청은 If-Modified-Since 또는 If-Unmodified-Since 헤더로 이와 같은 필드를 사용하여 만들어집니다.
62	Origin	HTTP, Reference, Request header, header, origin, 헤더
		Origin request 헤더는 fetch가 시작되는 위치입니다. 경로 정보는 포함하지 않고 서버 이름만 포함합니다. POST requests에 포함되는 것처럼, CORS requests 와 함께 전송합니다. Referer 헤더와 비슷하지만, origin 헤더는 전체 경로를 공개하지 않습니다.
63	Pragma	Deprecated, HTTP, 삭제됨, 요청, 캐싱, 헤더
		HTTP/1.0 의 Pragma  헤더는 요청-응답 체인에 다양한 영향을 줄 수 있는 구현관련 헤더이다. 이것은 HTTP/1.0 버전에서 HTTP/1.1 버전의 Cache-Control 헤더가 생기기 전 그것과 동일한 역할을 하는 대용 헤더로 사용되었다.
64	Range	HTTP, HTTP 헤더, 범위 요청, 요청 헤더, 참고사항
		Range HTTP 요청 헤더는 서버에게 문서의 일부분만 돌려주어야 한다는 것을 알려줍니다. Range 헤더를 통해 여러 부분을 한번에 요청할 수 있으며, 서버는 이러한 범위에 대해 문서의 여러 부분을 돌려보내줄 것입니다. 만약 서버가 돌려 보낸다면, 206 Partial Content를 응답으로 사용할 것입니다. 만약 범위가 유효하지 않다면, 서버는 416 Range Not Satisfiable 에러를 보낼 것입니다. 또한 서버는 Range 헤더를 무시하고 200 상태 코드와 함께 전체 문서를 돌려줄 수 있습니다.
65	Referer
		Referer 요청 헤더는 현재 요청된 페이지의 링크 이전의 웹 페이지 주소를 포함합니다. Referer 헤더는 사람들이 어디로부터 와서 방문 중인지를 인식할 수 있도록 해주며 해당 데이터는 예를 들어, 분석, 로깅, 혹은 캐싱 최적화에 사용될 수도 있습니다.
66	Retry-After
		Retry-After 응답 HTTP 헤더는 다음에 올 요청이 이루어지기 전에 사용자 에이전트가 대기해야 하는 시간을 가르킵니다. 이 헤더가 사용되는 주요한 두 가지 경우가 있습니다:
67	Server	HTTP, 참고자료, 헤더
		Server 헤더는 요청을 처리하기 위한 원(origin, 原) 서버의 소프트웨어 정보를 포함하고 있습니다.
68	Set-Cookie	HTTP, 레퍼런스, 응답, 쿠키, 헤더
		Set-Cookie HTTP 응답 헤더는 서버에서 사용자 브라우저에 쿠키를 전송하기 위해 사용됩니다.
69	Strict-Transport-Security
		HTTP Strict-Transport-Security response header (종종 HSTS 로 약칭) 는 HTTP 대신 HTTPS만을 사용하여 통신해야한다고 웹사이트가 브라우저에 알리는 보안 기능.
70	Transfer-Encoding
		Transfer-Encoding 헤더는 사용자에게 Entity header를 안전하게 전송하기 위해 사용하는 인코딩 형식을 지정합니다.
71	Vary
		Vary 헤더는 캐시 된 응답을 향후 요청들에서 오리진 서버로 새로운 요청 헤더를 요청하는 대신 사용할 수 있는지 여부를 결정합니다. 이것은 서버에서 컨텐츠 협상 알고리즘에 어떤 리소스를 선택을 할 것인지를 가르킵니다.
72	Via	한국어, 헤더
		Via 헤더는 요청헤더와 응답헤더에 포워드 프록시와 리버스 프록시에 의해서 추가 됩니다. 이 것은 포워드 메시지를 추적하거나, 요청 루프 방지, 요청과 응답 체인에 따라 송신자의 프로토콜 정보를 식별 합니다.
73	X-Forwarded-For	HTTP, HTTP 헤더, Reference, 비표준, 요청 헤더, 헤더
		X-Forwarded-For (XFF) 헤더는 HTTP 프록시나 로드 밸런서를 통해 웹 서버에 접속하는 클라이언트의 원 IP 주소를 식별하는 사실상의 표준 헤더다. 클라이언트와 서버 중간에서 트래픽이 프록시나 로드 밸런서를 거치면, 서버 접근 로그에는 프록시나 로드 밸런서의 IP 주소만을 담고 있다. 클라이언트의 원 IP 주소를 보기위해 X-Forwarded-For 요청 헤더가 사용된다.
74	X-Forwarded-Host	HTTP, HTTP Header, Non-standard, Reference, Request header, header, 레퍼런스, 비표준, 요청헤더, 헤더
		X-Forwarded-Host (XFH) 헤더는 HTTP 요청 헤더에서 클라이언트가 요청한 원래 Host 헤더를 식별하는 사실상의 표준 헤더입니다.
75	X-Forwarded-Proto
		X-Forwarded-Proto (XFP) 헤더는 클라이언트가 당신의 프록시 또는 로드 밸런서에 접속하는데에 사용했던 프로토콜(HTTP 또는 HTTPS)이 무엇인지 확인하는 사실상의 표준 헤더 입니다. 당신의 서버 접근 로그들은 서버와 로드 밸런서 사이에서 사용된 프로토콜을 포함하고 있습니다. 그러나 클라이언트와 로드밸런서에 사용한 프로토콜은 포함되어 있지 않습니다. 클라이언트와 로드밸런서 간의 사용된 프로토콜을 확인하기 위해서, X-Forwarded-Proto 요청 헤더가 사용되어 질 수 있습니다.
76	X-Frame-Options
		The X-Frame-Options HTTP 응답 헤더는 해당 페이지를 frame 또는iframe, object 에서 렌더링할 수 있는지 여부를 나타내는데 사용됩니다. 사이트 내 콘텐츠들이 다른 사이트에 포함되지 않도록 하여 clickjacking 공격을 막기 위해 이 헤더를 사용합니다.
77	X-XSS-Protection
		HTTP X-XSS-Protection헤더는 Internet Explorer, Chrome 및 Safari에서 제공하는 기능으로서, (XSS) 공격을 감지 할 때 페이지 로드를 중지시킬 수 있습니다. 최신 브라우저에서는 Inline Javascript('unsafe-inline')사용을 못하게 하는 CSP(Content-Security-Policy) 보호기능이 있으나, 해당 기능을 지원하지 않는 구형 웹브라우저에서 사용자를 보호 할수 있는 기능을 제공할 수 있습니다.
78	HTTP 메시지	Guide, HTTP, HTTP/1.1, HTTP/2, Response, request
		HTTP 메시지는 서버와 클라이언트 간에 데이터가 교환되는 방식입니다. 메시지 타입은 두 가지가 있습니다. 요청(request)은 클라이언트가 서버로 전달해서 서버의 액션이 일어나게끔 하는 메시지고, 응답(response)은 요청에 대한 서버의 답변입니다.
79	HTTP 요청 메서드	HTTP, Methods, Reference
		HTTP는 요청 메서드를 정의하여, 주어진 리소스에 수행하길 원하는 행동을 나타냅니다. 간혹 요청 메서드를 "HTTP 동사"라고 부르기도 합니다. 각각의 메서드는 서로 다른 의미를 구현하지만, 일부 기능은 메서드 집합 간에 서로 공유하기도 합니다. 이를테면 응답 메서드는 safe하거나, cacheable하거나, idempotent을 가질 수 있습니다.
80	CONNECT	HTTP, 요청 메소드, 참고사항
		HTTP CONNECT 메소드는 요청한 리소스에 대해 양방향 연결을 시작하는 메소드입니다. 이는 터널을 열기 위해서 사용될 수 있습니다.
81	DELETE	HTTP, Reference, Request method
		HTTP DELETE 메서드는 지정한 리소스를 삭제합니다.
82	GET	HTTP, Reference, Request method
		HTTP GET 메서드는 특정한 리소스를 가져오도록 요청합니다.
83	HEAD	HTTP, HTTP method, Reference
		HTTP HEAD 메서드는 특정 리소스를 GET 메서드로 요청했을 때 돌아올 헤더를 요청합니다.
84	OPTIONS	HTTP, 요청 메소드
		HTTP OPTIONS method 는 목표 리소스와의 통신 옵션을 설명하기 위해 사용됩니다. 클라이언트는 OPTIONS 메소드의 URL을 특정지을 수 있으며, aterisk(*) 를 통해 서버 전체를 선택할 수 있습니다.
85	PATCH
		HTTP PATCH 메소드는 리소스의 부분적인 수정을 할 때에 사용됩니다.
86	POST	HTTP, Reference, Request method
		HTTP POST 메서드는 서버로 데이터를 전송합니다. 요청 본문의 유형은 Content-Type 헤더로 나타냅니다.
87	PUT	HTTP, HTTP method, Reference, Request method
		HTTP PUT 메서드는 요청 페이로드를 사용해 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 대체합니다.
88	HTTP 개요	HTTP, Overview, WebMechanics, l10n:priority
		HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 protocol입니다. HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 합니다. 클라이언트-서버 프로토콜이란 (보통 웹브라우저인) 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미합니다. 하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등 불러온(fetched) 하위 문서들로 재구성됩니다.
89	HTTP range requests	HTTP, HTTP 범위 요청, 가이드
		HTTP 범위 요청은 HTTP의 일정 부분만 서버에서 클라이언트로 보내도록 허락하는 것입니다. 부분 요청은 예를들어 대형 미디어나 파일 다운로드 도중 일시정지와 다시 시작 기능에 유용합니다.
90	Redirections in HTTP
		URL 리다이렉션 혹은 URL 포워딩은 페이지 따위의 실제 리소스, 폼 혹은 전체 웹 애플리케이션이 다른 URL에 위치하고 있는 상태에서 링크를 존속시키는 기술입니다. HTTP는 많은 목표를 위해 사용되는 이런 동작을 수행하기 위해 특별한 종류의 응답인 HTTP 리다이렉트를 제공합니다: 사이트 유지관리가 진행 중인 상태에서의 일시적인 리다이렉션, 사이트 아키텍쳐의 변경 이후에도 외부 링크를 동작하는 상태로 유지시키기 위한 영구적인 리다이렉션, 파일 업로드 시 진행 상태 페이지 그리고 그 외의 수많은 리다이렉션들 ...
91	HTTP 리소스와 명세
		HTTP는 1990년 초에 처음으로 명세되었습니다. 확장성을 염두에 두고 설계하였고, 해를 거듭하면서 더 많은 추가 사항들이 세상에 나왔습니다; 이런 일로 많은 명세서를 통해 세상에 뿌려진 명세들이 나오게 되었습니다(실험되다가 폐기된 확장들 가운데에서도). 이 페이지에서는 HTTP와 관련해 의미가 있는 리소스들을 나열하고 있습니다.
92	Resources and URIs	HTTP, Overview, Reference
		HTTP는 브라우저 혹은 사용자 에이전트에게 인터넷 상 다른 리소스와의 통신을 허용합니다: 이를 위해 브라우저에는 자원의 신분(identity)와 위치(location)가 필요합니다. 이 두 비트의 정보는 URI로 설명됩니다.
93	A typical HTTP session
		HTTP와 같은 클라이언트-서버 프로토콜에서, 세션은 다음의 세 가지 과정으로 이루어집니다:
94	HTTP 상태 코드	HTTP, 상태 코드
		HTTP 응답 상태 코드는 특정 HTTP 요청이 성공적으로 완료되었는지 알려줍니다. 응답은 5개의 그룹으로 나누어집니다: 정보를 제공하는 응답, 성공적인 응답, 리다이렉트, 클라이언트 에러, 그리고 서버 에러. 상태 코드는 section 10 of RFC 2616에 정의되어 있습니다.
95	100 Continue	HTTP, Informational, Status code
		HTTP 100 Continue 정보 상태 응답 코드는 클라이언트가 서버로 보낸 요청에 문제가 없으니 다음 요청을 이어서 보내도 된다는 것을 의미합니다. 만약 클라이언트의 작업이 완료되었다면 이 응답은 무시해도 됩니다.
96	101 Switching Protocols	HTTP, HTTP Status Code, Informational, Reference, WebSockets
		HTTP 101 Switching Protocols는 클라이언트가 Upgrade 헤더를 통해 요청한 것에 따라 서버가 프로토콜을 바꾼다는 것을 알려주는 응답 코드입니다.
97	103 Early Hints
		HTTP 103 Early Hints 정보 상태 응답 코드는 서버가 응답을 준비하는 동안에도 사용자 에이전트가 자원을 미리 읽어들일 수 있도록, 주로 Link 헤더와 함께 사용됩니다.
98	200 OK	HTTP, Status code, Success
		HTTP 200 OK는 요청이 성공했음을 나타내는 성공 응답 상태 코드입니다.
99	201 Created	HTTP, Reference, Status code, Success
		HTTP 201 Created는 요청이 성공적으로 처리되었으며, 자원이 생성되었음을 나타내는 성공 상태 응답 코드입니다.
100	202 Accepted	HTTP, Reference, Status code
		HTTP 202 Accepted 는 요청이 성공적으로 접수되었으나, 아직 해당 요청에 대해 처리 중이거나 처리 시작 전임을 의미합니다. 요청이 처리 중 실패할 수도 있기 때문에 요청은 실행될 수도 실행되지 않을수도 있습니다.
101	204 No Content	HTTP, Reference, Status code, Success
		HTTP 204 No Content 성공 상태 응답 코드는 요청이 성공했으나 클라이언트가 현재 페이지에서 벗어나지 않아도 된다는 것을 나타냅니다.
102	205 Reset Content
		HTTP의 205 Reset Content 응답상태는 form의 내용을 지우거나 캔버스 상태를 재설정하거나 UI를 새로 고치려면 client의 문서뷰를 새로고침하라고 알려준다.
103	206 Partial Content	HTTP, HTTP Status, Range Requests, Success, 성공
		HTTP 206 Partial Content는 Range 헤더에 기술된 데이터 범위에 대한 요청이 성공적으로 응답되어 바디에 해당되는 데이터를 담고 있다는 것을 알려줍니다.
104	301 Moved Permanently
		HTTP 301 Moved Permanently 리다이렉트 상태 응답 코드는 요청한 리소스가 Location 헤더에 주어진 URL로 완전히 옮겨졌다는 것을 나타낸다. 브라우저는 이 페이지로 리다이렉트하고, 검색 엔진은 해당 리소스로 연결되는 링크를 갱신한다[검색엔진 최적화의 관점에서는 '원 콘텐츠가 새로운 URL로 옮겨졌다'(the link-juice is sent to the new URL)고 한다].
105	302 Found	HTTP, HTTP 상태 코드, 레퍼런스, 리다이렉트
		하이퍼텍스트 전송 프로토콜 (HTTP)의 302 Found 리다이렉트 상태 응답 코드는 클라이언트가 요청한 리소스가 Location 헤더에 주어진 URL에 일시적으로 이동되었음을 가리킨다. 브라우저는 사용자를 이 URL의 페이지로 리다이렉트시키지만 검색 엔진은 그 리소스가 일시적으로 이동되었다고 해서 그에 대한 링크를 갱신하지는 않는다 ('SEO 관점' 에서 말하자면, 링크 주스(Link Juice)가 새로운 URL로 보내지지는 않는다).
106	304 Not Modified	HTTP, Redirection, Reference, Status code, contents verification
		No summary!
107	307 Temporary Redirect
		HTTP 307 Temporary Redirect 리다이렉트 상태 응답 코드는 요청한 리소스가 Location 헤더에 주어진 URL 로 임시로 옮겨졌다는 것을 나타냅니다.
108	400 Bad Request	HTTP 상태 코드, 상태 코드
		HyperText Transfer Protocol (HTTP) 400 Bad Request 응답 상태 코드는 서버가 클라이언트 오류(예: 잘못된 요청 구문, 유효하지 않은 요청 메시지 프레이밍, 또는 변조된 요청 라우팅) 를 감지해 요청을 처리할 수 없거나, 하지 않는다는 것을 의미합니다.
109	401 Unauthorized	Client error, HTTP, Reference, Status code, 클라이언트 오류
		No summary!
110	403 Forbidden	상태 코드
		No summary!
111	404 Not Found	브라우저, 상태 코드
		HTTP 404 Not Found 클라이언트 오류 응답 코드는 서버가 요청받은 리소스를 찾을 수 없다는 것을 의미합니다. 404 페이지를 띄우는 링크는 대체로 브로큰 링크(broken link) 또는 데드 링크(dead link)라고 부르며, link rot 대상일 수도 있습니다.
112	405 Method Not Allowed
		하이퍼텍스트 전송 프로토콜(HTTP)의 405 Method Not Allowed 응답 상태 코드는 요청 방법이 서버에 의해 알려졌으나, 사용 불가능한 상태임을 가리킵니다.
113	408 Request Timeout
		HyperText Transfer Protocol (HTTP) 408 Request Timeout 응답 상태 코드는 서버가 사용하지 않는 연결을 끊고 싶다는 것을 의미한다. 서버가 클라이언트의 요청 없이도 유휴 상태의 연결에 전송한다.
114	409 Conflict
		HTTP 409 Conflict 응답 상태 코드는 서버의 현재 상태와 요청이 충돌했음을 나타낸다.
115	411 Length Required
		No summary!
116	413 Payload Too Large
		No summary!
117	416 Range Not Satisfiable	HTTP, 상태 코드, 클라이언트 에러
		하이퍼텍스트 트랜스퍼 프로토콜(HTTP) 416 Range Not Satisfiable 에러 응답 코드는 서버가 요청받은 범위에 대해서 서비스 할 수 없음을 알려줍니다. 아마도 이유는 그 문서가 그러한 범위를 지니고 있지 않거나, 또는 Range 헤더 값이 문법적으로는 옳지만, 이해가 되지 않을 경우 그럴 수 있습니다.
118	418 I'm a teapot	HTTP, HTTP 상태 코드, Reference
		HTTP 418 I'm a teapot 클라이언트 오류 응답 코드는 서버가 찻주전자이기 때문에 커피 내리기를 거절했다는 것을 의미합니다. 이 오류는 1998년 만우절 농담이었던 하이퍼 텍스트 커피 포트 제어 규약(Hyper Text Coffee Pot Control Protocol)의 레퍼런스입니다.
119	422 Unprocessable Entity	Client error, HTTP, HTTP Status Code, Reference, Status code, WebDAV
		이 응답은 서버가 요청을 이해하고 요청 문법도 올바르지만 요청된 지시를 따를 수 없음을 나타냅니다.
120	431 Request Header Fields Too Large
		HTTP 431 Request Header Fields Too Large 응답 코드는 HTTP 헤더의 크기가 너무 크기 때문에 처리가 불가능함을 알려준다. 요청 헤더의 크기를 줄인 후, 재요청을 할 수 있다.
121	500 Internal Server Error	HTTP, Server error, Status code
		하이퍼텍스트 전송 프로토콜 (HTTP) 500 Internal Server Error 서버 에러 응답 코드는 요청을 처리하는 과정에서 서버가 예상하지 못한 상황에 놓였다는 것을 나타냅니다.
122	501 Not Implemented
		HyperText Transfer Protocol (HTTP) 501 Not Implemented 서버 응답 코드는 요청을 수행할 수 있는 기능을 서버가 지원하지 않는다는 것을 의미합니다.요청자에게 서버에서 기능이 지원될 때, 다시 확인해볼 수 있도록
123	502 Bad Gateway
		HyperText Transfer Protocol (HTTP) 502 Bad Gateway 에러 응답코드는, 서버가 게이트웨이나 프록시 서버 역할을 하면서 업스트림 서버로부터 유효하지 않은 응답을 받았다는 것을 가르킨다.
124	503 Service Unavailable	503, HTTP, Server error, Status code
		하이퍼텍스트 전송 프로토콜 (HTTP) 503 Service Unavailable 서버 에러 응답(response) 코드는 서버가 요청(request)을 처리할 준비가 되지 않은 것을 나타낸다.
125	504 Gateway Timeout
		하이퍼텍스트 전송 프로토콜 (HTTP) 504 Gateway Timeout 서버 에러 응답 코드는 서버가 게이트웨이(gateway) 혹은 프록시(proxy)의 역할을 하는 동안 시간 안에 업스트림 서버(upstream server)로부터 요청을 마치기 위해 필요한 응답를 받지 못 했음을 나타냅니다.
126	505 HTTP Version Not Supported
		505 HTTP Version Not Supported 응답 코드는 요청에 사용된 HTTP 버전이 서버가 지원하지 않음을 알립니다.