프론트엔드 개발자가 꼭 알아야 할 http 프로토콜에 대한 지식

http(Hypertext Transfer Protocol)는 요청 및 응답 모드를 기반으로 하는 상태 비저장 애플리케이션 계층 프로토콜로, 종종 TCP 연결 방법을 기반으로 합니다. 프론트엔드 개발자가 꼭 알아야 할 http 프로토콜 관련 지식에 대해 이야기하는 글입니다.

1. 개념

HTTP(Hypertext Transfer Protocol)는 요청 및 응답 모드를 기반으로 하는 상태 없는 애플리케이션 계층 프로토콜로, 종종 TCP 연결 방식을 기반으로 합니다. HTTP1 버전은 지속적인 연결을 제공합니다. 연결 메커니즘 대부분의 웹 개발은 HTTP 프로토콜을 기반으로 구축된 웹 애플리케이션입니다.

2. Development

버전 0.9(get만 지원) - 1.0 - 1.1 - 2.0(개발 중)

버전 0.9는 평가판으로만 간주되며 도입되지 않습니다. 주로 1.0과 1.1의 차이점에 대해 이야기합니다.

2.1 영구 연결 및 비영구 연결

버전 1.0은 비영구 연결을 지원합니다. 즉, TCP 프로토콜(http는 TCP 기반 응용 프로그램 계층 프로토콜)의 3방향 핸드셰이크 후에 연결을 설정한다는 의미입니다. , 서버는 하나의 개체만 브라우저에 보낼 수 있으며, 그러면 링크 연결이 끊어집니다. 웹 페이지에 이미지, js 파일, CSS 파일 등과 같은 다른 인라인 개체가 포함되어 있으면 여러 링크를 설정해야 합니다. 여러 번 연결/연결을 끊는 오버헤드. 버전 1.1은 연결이 설정된 후 여러 개체를 보낼 수 있으므로 이론적으로 버전 1.1이 1.0보다 더 빠르고 빠릅니다. 그러나 일부 네티즌은 1.0이 더 빠르다고 말합니다. 그것.

2.2 호스트 도메인

호스트 헤더 필드는 요청된 리소스의 인터넷 호스트와 포트 번호를 지정하고 요청된 URL의 원래 서버 또는 게이트웨이의 위치를 ​​나타내야 합니다. HTTP/1.1 요청에는 호스트 헤더 필드가 포함되어야 합니다. 그렇지 않으면 시스템은 400 상태 코드를 반환합니다. 이 필드는 아마도 속도를 높이기 위해 필요하지 않은 것처럼 느껴집니다. 결국 HOST를 직접 지정하면 해당 호스트를 더 빨리 찾을 수 있습니다. 호스트가 존재하지 않는 경우에도 더 빨리 찾을 수 있습니다.

2.3 대역폭 최적화

버전 1.1은 부분 리소스 요청을 지원하며 리소스의 일부만 요청할 수 있습니다. 동시에 버전 1.1에서는 요청 엔터티가 큰 경우 먼저 100 상태 코드가 포함된 헤더 필드를 보내 서버가 요청에 응답할 수 있는지 확인할 수 있습니다. 응답이 없는 상황에서 특정 시간에 대역폭을 절약할 수 있도록 다시 전송됩니다.户 구체적인 절차: 클라이언트 - 100 상태 코드가 포함된 요청 헤드 전송 - 서버는 응답할 수 있는지 확인하고, 응답할 수 없는 경우 해당 상태 코드(예: 401, 인증되지 않음)를 반환하고, 가능하면 100 상태 코드를 반환합니다. can, return 100 status code ——클라이언트는 반환된 상태 코드를 기반으로 요청을 계속 보낼지 여부를 확인합니다.

2.4 요청 방법 및 상태 코드

HTTP1.1에 요청 방법 OPTIONS, PUT, DELETE, TRACE, CONNECT가 추가되었습니다.

HTTP/1.0에는 16개의 상태 응답 코드만 정의되어 있으며 오류나 경고에 대한 프롬프트는 구체적이지 않습니다. 충분한 . HTTP/1.1은 오류 또는 경고 정보에 대한 설명을 추가하기 위해 경고 헤더 필드를 도입했습니다.

       24개의 새로운 상태 응답 코드가 HTTP/1.1에 추가되었습니다. 예를 들어 요청된 리소스가 리소스의 현재 상태와 충돌함을 나타내는 409(충돌), 서버의 리소스가 영구적으로 삭제되었음을 나타내는 410(사라짐) 등이 있습니다. .

3. HTTP 통신 프로세스 (1) URL에 따라 DNS를 쿼리하고 웹 서버를 찾은 후 해당 서버와 tcp 연결을 설정합니다(http의 하위 계층 프로토콜).

(2) 그러면 웹 브라우저가 서버에 요청을 보냅니다.请 요청에는 일반적으로 다음이 포함됩니다. | 요청 헤더 | 요청 텍스트 예:

get /Hello.jpg http/1.1

수락: Image/gif.image/jpeg

Accept-Language:zh-cn

연결: Keep-Alive

호스트:127.0.0.1 사용자 에이전트:Mozila/4.0(호환;MSIE5.01;Window NT5.0)

사용 사용 사용  -                                                          off off 's's 's           out out through out out out out out out out out out out out out out out out out'   ' ‐ ‐ ‐ ‐‐ 그리고 . 응답 패키지에는 일반적으로 다음이 포함됩니다. |프로토콜 버전 상태 코드 설명|응답 헤더|응답 텍스트

                                                                                                                                        상태 코드 13: 23:42 GMT

콘텐츠 길이: 188

4. http 헤더 필드

이 부분은 내용이 너무 자세해서 표에 직접 나열되어 있습니다.

요청 헤더:

Accept-Ranges인증 Cache-ControlConnectionCookieContent-LengthContent-TypeDateExpectFromHostIf-Match If-수정-이후 If-Unmodified-SinceMax-ForwardsPragmaProxy-AuthorizationRangeRefererTE업그레이드User-AgentWarn: 199 Miscellaneous warning

응답 헤더:

Header	Explanation	Example
Accept	클라이언트가 수신할 수 있는 콘텐츠 유형을 지정하세요	Accept: text/plain, text/html
Accept -Charset	브라우저 허용되는 문자 인코딩 세트입니다.	Accept-Charset: iso-8859-5
Accept-Encoding	브라우저가 지원할 수 있는 웹 서버에서 반환한 콘텐츠 압축 인코딩 유형을 지정합니다.	Accept-Encoding: 압축, gzip
Accept-Language	Accept-Language: en,zh
하나 이상의 웹 페이지 엔터티를 요청할 수 있습니다. 하위 범위 필드	Accept -범위: 바이트
HTTP 인증에 대한 인증 인증서	인증: 기본 QWxhZGRpbjpvcGVuIHNlc2FtZQ==
요청 및 응답에 따른 캐싱 메커니즘 지정	캐시 -제어: 아니요- 캐시
은 지속적인 연결이 필요한지 여부를 나타냅니다. (HTTP 1.1은 기본적으로 영구 연결을 사용합니다.)	Connection: close
HTTP 요청이 전송되면 요청한 도메인 이름에 저장된 모든 쿠키 값이 웹 서버로 전송됩니다.	Cookie: $Version=1; Skin=new;
요청된 콘텐츠 길이	Content-Length: 348
엔터티에 해당하는 요청된 MIME 정보	Content-Type: application/x-www-form-urlencoded
요청이 전송된 날짜 및 시간	Date: 2010년 11월 15일 화요일 08:12:31 GMT
요청된 특정 서버 동작	예상: 100-continue
요청한 사용자의 이메일	From: user@email.com
도메인 이름과 포트를 지정하세요. 요청한 서버 번호	Host: www.zcmhi.com
요청 내용이 엔터티와 일치하는 경우에만 유효합니다.	If-Match: "737060cd8c284d8af7ad3082f209582d"
요청한 경우 지정된 시간 이후에 해당 부분이 수정되면 요청이 성공합니다. 수정되지 않은 경우 내용이 변경되지 않은 경우 304 코드가 반환됩니다. 서버에서 이전에 보낸 Etag를 서버에서 응답한 Etag와 비교하여 변경되었는지 확인합니다. 서버 클라이언트의 누락된 부분을 보내고, 그렇지 않으면 전체 엔터티를 보냅니다. 매개변수도 Etag	If-Range: "737060cd8c284d8af7ad3082f209582d"
요청은 지정된 시간 이후에 엔터티가 수정되지 않은 경우에만 성공합니다	If-Unmodified-Since: Sat , 29 Oct 2010 19:43:31 GMT
정보가 프록시 및 게이트웨이를 통해 전송되는 시간을 제한하세요	Max-Forwards: 10
구현 관련 내용을 포함하는 데 사용됩니다. 지침	Pragma: no -cache
프록시에 연결된 인증 인증서	Proxy-Authorization: 기본 QWxhZGRpbjpvcGVuIHNlc2FtZQ==
엔티티의 일부만 요청하고, range	Range: bytes=500- 999
이전 웹페이지 주소, 현재 요청한 웹페이지 바로 따라가는 길, 즉 가는 길	Referer: http://www.zcmhi .com/archives/71.html
클라이언트가 수락할 전송 인코딩이며, 테일과 헤더 정보를 수락하도록 서버에 알립니다.	TE: trails,deflate;q=0.5
서버에서 변환할 수 있도록 특정 전송 프로토콜을 서버에 지정합니다(지원되는 경우)	업그레이드: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
User-Agent의 내용에는 요청한 사용자 정보가 포함되어 있습니다	User-Agent: Mozilla/5.0 (Linux ;

Accept-Ranges: bytesAge원본 서버에서 프록시 캐시 형성까지의 예상 시간(초, 음수 아님) Age: 12Allow특정 네트워크 리소스에 대한 유효한 요청 동작, 허용되지 않으면 405가 반환됩니다. 캐시할 수 있는 캐싱 메커니즘의 여부와 유형은 무엇입니까? #웹 서버에서 지원하는 반환된 콘텐츠 압축 인코딩 유형입니다. Content-Encoding: gzipContent-Language응답 본문의 언어Content-Length#🎜🎜 #Content- 길이: 348Content-Location리소스에 대한 다른 대체 주소 요청 Content- 위치 : /index.htmContent-MD5리소스의 MD5 검사 값을 반환합니다Content- MD5: Q2hlY2sgSW50ZWdyaXR5IQ==Content-Range전체 반환 본문에서 이 부분의 바이트 위치콘텐츠의 MIME 유형 반환# 🎜🎜 #Content-Type: text/html; charset=utf-8Date원본 서버 메시지가 전송된 시간# 🎜🎜## 🎜🎜#날짜: 2010년 11월 15일 화요일 08:12:31 GMTETag현재 값 요청 변수의 엔터티 태그# 🎜🎜##🎜 🎜#응답 만료 날짜 및 시간 # 🎜🎜##🎜🎜 #만료: 2010년 12월 1일 목요일 16:00:00 GMT최종 수정최종 수정 요청한 리소스의 시간#🎜🎜 ## 🎜🎜#은 수신을 리디렉션하는 데 사용됩니다. 요청을 완료하거나 새 리소스를 식별하려면 요청하지 않은 URL의 위치로 이동하세요. Location: http://www.zcmhi.com/archives/94 .html#🎜 🎜##🎜🎜 #Pragma: no-cache# 기본 Retry-After엔터티를 일시적으로 사용할 수 없는 경우 지정된 시간 후에 다시 시도하도록 클라이언트에 알립니다. 이름서버: Apache/1.3.27(Unix)(Red-Hat/Linux)#🎜🎜 ## 🎜🎜#SET Http CookieSet-Cookie: UserID=JohnDoe; =1Trailer#🎜 🎜#Transfer-Encoding# 🎜🎜#File Transfer EncodingTransfer-Encoding: 청크#🎜🎜 #다운스트림에 알리기 프록시가 캐시된 응답을 사용하는지 아니면 원본 서버의 요청을 사용하는지 프록시 클라이언트에게 알립니다. 은 다음을 나타냅니다. 클라이언트가 엔터티를 요청하기 위해 사용해야 하는 인증 체계

Header

설명

예

Accept-Ranges

서버가 지정된 범위 요청을 지원하는지 여부와 분할된 요청 유형을 나타냅니다. # 🎜🎜#

# 🎜 🎜#Content-Language: en,zh

응답 본문의 길이

#🎜🎜 #Content-Range: 바이트 21010-47021/47022

Content-Type

ETag: "737060cd8c284d8af7ad3082f209582d"

Expires

최종 수정: 2010년 11월 15일 화요일 12:45:26 GMT

위치

Pragma

응답 체인의 모든 수신자에 적용할 수 있는 구현별 지시문 포함

refresh

은 리디렉션에 적용되거나 새 리소스가 생성되어 5 이후 리디렉션됩니다. 초 (Netscape에서 제안, 대부분의 브라우저 지원) //www.zcmhi.com/archives/94.html

Set-Cookie

청크 분할 전송 인코딩 끝에 헤더 필드가 존재함을 나타냅니다.

Trailer : Max-Forwards

Vary

Vary: 응답은 어디로 전송되나요?

Via: 1.0 fred, 1.1where.com(Apache/1.1)

Warning#🎜🎜 ## 🎜🎜#경고 엔터티 가능한 문제

경고: 199 기타 경고

WWW-인증

WWW-인증: 기본

5. http 요청 방식

GET Request-URI로 식별되는 리소스를 얻기 위한 요청
POST Request-URI로 식별되는 리소스 뒤에 새로운 데이터 추가
HEAD Request-URI로 식별되는 리소스를 얻기 위해 요청 응답 메시지 헤더
PUT는 서버에 리소스를 저장하도록 요청하고 Request-URI를 식별자로 사용합니다.
DELETE는 서버에 Request-URI로 식별된 리소스를 삭제하도록 요청합니다.
TRACE는 주로 수신된 요청 정보를 서버에 다시 보내도록 요청합니다. 테스트 또는 진단용
CONNECT 향후 사용을 위해 예약됨
서버 성능을 쿼리하거나 리소스 관련 옵션 및 요구 사항을 쿼리하기 위한 OPTIONS 요청

6. 상태 코드

응답 메시지의 첫 번째 줄은 다음과 같습니다. HTTP 프로토콜 버전 번호, 상태 코드 및 상태 메시지로 구성된 상태 줄이라고 불리는 것은 세 부분으로 구성됩니다.

　상태 코드는 HTTP 서버가 예상되는 응답을 생성했는지 여부를 HTTP 클라이언트에 알리는 데 사용됩니다.

　 HTTP/1.1에서는 5가지 유형의 상태 코드를 정의합니다. 첫 번째 숫자는 응답 유형을 정의합니다.

　 1XX 프롬프트 메시지 - 요청이 성공적으로 수신되었으며 계속 처리되고 있음을 나타내며, 요청을 완료하려면 데이터를 계속 수신해야 함을 나타냅니다.

　 2XX 성공 - 요청이 성공적으로 수신되고 이해되었으며 수락되었음을 나타냅니다.

3XX 리디렉션 - 요청을 완료하려면 추가 처리를 수행해야 합니다.

4XX 클라이언트 오류 - 요청에 구문 오류가 있거나 요청을 구현할 수 없습니다.

5XX 서버 오류 - 서버가 법적 요청을 구현하지 못했습니다.

상태 코드 목록

표 1(표에 대한 간략한 소개, 소개는 간결하고 명확합니다. 그렇지 않은 경우 먼저 이 표를 확인하는 것이 좋습니다. 이해가 안 되신다면 아래 표 2를 확인해 보세요)

Multiple ChoicesBAD 요청 결제 필요Forbidden Not Found메소드가 허용되지 않음허용되지 않습니다. 프록시 인증 필요요청 시간 초과Con conflictGone413

상태 코드	상태 코드 영문 이름	중국어 설명
1
100	으로 시작하는 상태 코드Continue	Continue. 클라이언트는
101	프로토콜 전환	프로토콜 전환 요청을 계속해야 합니다. 서버는 클라이언트의 요청에 따라 프로토콜을 전환합니다. 고급 프로토콜로만 전환할 수 있습니다. 예를 들어 새 버전의 HTTP 프로토콜
2으로 전환할 수 있습니다.
200	OK	으로 시작하는 상태 코드는 성공입니다. 일반적으로 GET 및 POST 요청에 사용됩니다
201	Created	이 생성되었습니다. 성공적으로 요청하고 새 리소스를 만들었습니다
202	Accepted	Accepted. 요청이 수락되었지만 처리가 완료되지 않았습니다
203	공인되지 않은 정보	공인되지 않은 정보입니다. 요청이 성공했습니다. 하지만 반환된 메타정보는 원본 서버에 있는 것이 아니라 복사본
204	콘텐츠 없음	콘텐츠 없음. 서버가 성공적으로 처리되었지만 콘텐츠가 반환되지 않았습니다. 웹 페이지
205	콘텐츠 재설정	콘텐츠 재설정 없이 브라우저가 현재 문서를 계속 표시하도록 합니다. 서버 처리가 성공적으로 완료되었으며 사용자 단말기(예: 브라우저)는 문서 보기를 재설정해야 합니다. 이 반환 코드는 브라우저의 양식 필드
206	부분 콘텐츠	를 지우는 데 사용할 수 있습니다. 서버가 3
300
Multiple Choices로 시작하는 GET 요청		상태 코드의 일부를 성공적으로 처리했습니다. 요청된 리소스에는 여러 위치가 포함될 수 있으며 이에 따라 사용자 단말기(예: 브라우저)에 대해 리소스 특성 및 주소 목록이 반환되어
301	Moved Permanently	Permanently moved를 선택할 수 있습니다. 요청된 리소스는 새 URI로 영구적으로 이동되었으며 반환 정보에는 새 URI가 포함되며 브라우저는 자동으로 새 URI로 이동됩니다. 앞으로 새로운 요청은
302	Found	임시 이동 대신 새 URI를 사용해야 합니다. 301과 비슷합니다. 그러나 리소스는 일시적으로만 이동됩니다. 클라이언트는 계속해서 원본 URI
303	See Other	를 사용해야 다른 주소를 볼 수 있습니다. 301과 비슷합니다. GET 및 POST 요청을 사용하여
304	Not Modified	Unmodified를 확인하세요. 요청한 리소스가 수정되지 않았습니다. 서버가 이 상태 코드를 반환하면 리소스가 반환되지 않습니다. 클라이언트는 일반적으로 클라이언트가 지정된 날짜 이후에 수정된 리소스만 반환하려고 함을 나타내는 헤더를 제공하여 액세스된 리소스를 캐시합니다.
305	프록시 사용	프록시 사용. 요청된 리소스는 프록시
306	Unused	사용되지 않는 HTTP 상태 코드
307	Temporary Redirect	Temporary Redirect를 통해 액세스해야 합니다. 302와 비슷합니다. 사용 요청 리디렉션 사용 redStatus 코드 4
400
클라이언트 요청의 구문 오류로, 서버는 이해할 수 없습니다. 사용자 신원 인증		402
향후 사용을 위해 예약됨		403
서버가 클라이언트의 요청을 이해하지만 이 요청 실행을 거부함		4 04
Server 클라이언트의 요청에 따라 리소스(웹페이지)를 찾을 수 없습니다. 이 코드를 통해 웹 사이트 디자이너는 "요청한 리소스를 찾을 수 없습니다"라는 개인 페이지를 설정할 수 있습니다.		405
클라이언트 요청의 메서드가 금지되었습니다		406
클라이언트가 요청한 콘텐츠 특성에 따라 서버가 요청을 완료할 수 없습니다		407
요청에는 401과 유사한 프록시 인증이 필요하지만 요청자는 승인을 위해 프록시를 사용해야 합니다		408
서버가 클라이언트가 보낸 요청을 너무 오래 기다려서 시간이 초과되었습니다		409
서버는 클라이언트의 PUT 요청을 완료할 때 이 코드를 반환할 수 있습니다. 서버가 요청을 처리할 때 충돌이 발생했습니다		410
클라이언트가 요청한 리소스가 더 이상 존재하지 않습니다. 410은 404와 다릅니다. 리소스가 영구적으로 삭제된 경우 웹사이트 디자이너는 301 코드를 통해 리소스의 새 위치를 지정할 수 있습니다. 전제조건 실패	클라이언트 요청 정보에 대한 전제조건 오류
요청 엔터티가 너무 큼	요청한 엔터티가 너무 커서 서버에서 처리할 수 없습니다. 클라이언트의 지속적인 요청을 방지하기 위해 서버는 연결을 닫을 수 있습니다.서버가 일시적으로 처리할 수 없는 경우 Retry-After 응답 메시지가 포함됩니다
414	Request-URI Too Large	요청된 URI가 너무 깁니다(URI는 일반적으로 URL임). 서버가 처리할 수 없습니다
415	지원되지 않는 미디어 유형	서버가 요청에 첨부된 미디어 형식을 처리할 수 없습니다
416	요청 범위가 만족스럽지 않습니다	클라이언트가 요청한 범위가 잘못되었습니다
417	Expectation Failed	서버가 Expect 요청 헤더 정보를 충족할 수 없습니다.
5
500	내부 서버 오류	서버에 내부 오류가 발생하여 요청을 완료할 수 없습니다.
501	구현되지 않음	서버가 요청한 기능을 지원하지 않습니다. 요청을 완료할 수 없습니다.
502	잘못된 게이트웨이	게이트웨이 또는 프록시 역할을 하는 서버가 다음 서버로부터 잘못된 요청을 받았습니다. 원격 서버
503	Service Unavailable	서버 과부하 또는 시스템 점검으로 인해 일시적으로 서버를 사용할 수 없습니다. 클라이언트의 요청을 처리할 수 없습니다. 지연 시간은 서버의 Retry-After 헤더 정보에 포함될 수 있습니다
504	Gateway Time-out	게이트웨이 또는 프록시 역할을 하는 서버가 원격 서버의 요청을 제때에 받지 못했습니다
505	지원되지 않는 HTTP 버전	서버가 요청한 HTTP 프로토콜 버전을 지원하지 않아 처리를 완료할 수 없습니다

표 2 상세 소개표

마지막으로 대부분의 정보는 인터넷에서 수집되었습니다. 기여해주신 모든 선배님들께 감사드립니다! 【추천 강좌: http 동영상 튜토리얼

상태 코드	의미
100	클라이언트는 계속해서 요청을 보내야 합니다. 이 임시 응답은 요청의 일부가 서버에 의해 수신되었으며 아직 거부되지 않았음을 클라이언트에 알리는 데 사용됩니다. 클라이언트는 요청의 나머지 부분을 계속 보내야 하며, 요청이 이미 완료된 경우 이 응답을 무시해야 합니다. 서버는 요청이 완료된 후 클라이언트에 최종 응답을 보내야 합니다.
101	서버는 클라이언트의 요청을 이해했으며 업그레이드 메시지 헤더를 통해 클라이언트에게 다른 프로토콜을 사용하여 요청을 완료하도록 알립니다. 이 응답의 마지막 빈 줄을 보낸 후 서버는 업그레이드 헤더에 정의된 프로토콜로 전환합니다. 새로운 프로토콜로 전환하는 것이 더 유리할 경우에만 유사한 조치를 취해야 합니다. 예를 들어, 이전 버전이 아닌 새로운 HTTP 버전으로 전환하거나, 이러한 기능을 활용하는 리소스를 전달하기 위해 실시간 및 동기 프로토콜로 전환하면 이점이 있습니다.
102	WebDAV(RFC 2518)에 의해 확장된 상태 코드로, 처리가 계속됨을 나타냅니다.
200	요청이 성공했으며 요청에서 예상하는 응답 헤더 또는 데이터 본문이 이 응답과 함께 반환됩니다.
201	요청이 구현되었으며 요청의 요구 사항에 따라 새 리소스가 생성되었으며 해당 URI가 Location 헤더 정보와 함께 반환되었습니다. 필요한 리소스를 제때 생성할 수 없는 경우 '202 Accepted'를 반환해야 합니다.
202	서버가 요청을 수락했지만 아직 처리하지 않았습니다. 거부될 수 있는 것처럼 요청도 궁극적으로 실행될 수도 있고 실행되지 않을 수도 있습니다. 비동기 작업의 경우 이 상태 코드를 보내는 것보다 더 편리한 방법은 없습니다. 202 상태 코드 응답을 반환하는 목적은 일괄 작업이 완료될 때까지 클라이언트를 서버에 연결하지 않고도 서버가 다른 프로세스의 요청(예: 하루에 한 번만 수행되는 일괄 기반 작업)을 수락할 수 있도록 하는 것입니다. 완료되었습니다. 요청 처리를 수락하고 202 상태 코드를 반환하는 응답에는 반환된 엔터티에 처리의 현재 상태를 나타내는 일부 정보와 처리 상태 모니터 또는 상태 예측에 대한 포인터가 포함되어 사용자가 작업 여부를 추정할 수 있습니다. 완료되었습니다.
203	서버가 요청을 성공적으로 처리했지만 반환된 엔터티 헤더 메타 정보는 원래 서버에서 유효한 명확한 세트가 아니라 로컬 또는 제3자의 복사본입니다. 현재 정보는 원래 버전의 하위 집합이거나 상위 집합일 수 있습니다. 예를 들어, 리소스에 대한 메타데이터를 포함하면 원본 서버가 메타데이터에 대한 상위 정보를 알 수 있습니다. 이 상태 코드를 사용할 필요는 없으며 이 상태 코드 없이 응답이 200 OK를 반환한 경우에만 적합합니다.
204	서버가 요청을 성공적으로 처리했지만 엔터티 콘텐츠를 반환할 필요가 없으며 업데이트된 메타 정보를 반환하려고 합니다. 응답은 엔터티 헤더 형식으로 새롭거나 업데이트된 메타정보를 반환할 수 있습니다. 이러한 헤더가 있는 경우 요청된 변수와 일치해야 합니다. 클라이언트가 브라우저인 경우 사용자의 브라우저는 보기에 있는 문서 사양에 따라 새롭거나 업데이트된 메타정보가 사용자의 브라우저 활동에 적용되어야 하는 경우에도 문서 보기를 변경하지 않고 요청이 이루어진 페이지를 유지해야 합니다. 204 응답은 메시지 본문을 포함하는 것이 금지되어 있으므로 항상 메시지 헤더 뒤의 첫 번째 빈 줄로 끝납니다.
205	서버가 요청을 성공적으로 처리했지만 아무것도 반환하지 않았습니다. 그러나 204 응답과 달리 이 상태 코드를 반환하는 응답에서는 요청자가 문서 보기를 재설정해야 합니다. 이 응답은 주로 사용자 입력을 수락한 후 즉시 양식을 재설정하여 사용자가 다른 입력을 쉽게 시작할 수 있도록 하는 데 사용됩니다. 204 응답과 마찬가지로 이 응답은 메시지 본문을 포함할 수 없으며 메시지 헤더 다음의 첫 번째 빈 줄로 끝납니다.
206	서버가 GET 요청의 일부를 성공적으로 처리했습니다. FlashGet 또는 Thunder와 같은 HTTP 다운로드 도구는 이러한 유형의 응답을 사용하여 중단된 다운로드를 재개하거나 동시 다운로드를 위해 대용량 문서를 여러 다운로드 세그먼트로 나눕니다. 요청에는 클라이언트가 얻으려는 콘텐츠 범위를 나타내는 Range 헤더가 포함되어야 하며 요청 조건으로 If-Range가 포함될 수 있습니다. 응답에는 다음 헤더 필드가 포함되어야 합니다. Content-Range는 Content-Type multipart/byteranges가 포함된 멀티파트 다운로드인 경우 이 응답에 반환된 콘텐츠 범위를 나타내는 데 사용됩니다. 각 단락에는 이 단락의 콘텐츠 범위를 나타내는 Content-Range 필드가 포함되어야 합니다. Content-Length가 응답에 포함된 경우 해당 값은 반환되는 콘텐츠 범위의 실제 바이트 수와 일치해야 합니다. 동일한 요청이 200 응답을 반환해야 하는 경우 날짜 ETag 및/또는 Content-Location입니다. Expires, Cache-Control 및/또는 Vary(해당 값이 동일한 변수에 대한 이전의 다른 응답에 해당하는 값과 다를 수 있는 경우)이 응답 요청이 If-Range 강력한 캐시 확인을 사용하는 경우 이 응답 요청이 다음을 사용하는 경우 이 응답에는 다른 엔터티 헤더가 포함되어서는 안 됩니다. If-Range 약한 캐시 검증인 경우 이 응답은 다른 엔터티 헤더를 포함하는 것이 금지됩니다. 이렇게 하면 캐시된 엔터티 콘텐츠와 업데이트된 엔터티 헤더 정보 간의 불일치가 방지됩니다. 그렇지 않으면 이 응답에는 200 응답으로 반환되어야 하는 모든 엔터티 헤더 필드가 포함되어야 합니다. ETag 또는 Last-Modified 헤더가 정확히 일치하지 않는 경우 클라이언트 캐시는 206 응답에서 반환된 콘텐츠를 이전에 캐시된 콘텐츠와 결합해서는 안 됩니다. Range 및 Content-Range 헤더를 지원하지 않는 캐시는 206 응답에서 반환된 콘텐츠를 캐시하는 것이 금지됩니다.
207	WebDAV(RFC 2518)에 의해 확장된 상태 코드는 후속 메시지 본문이 XML 메시지가 되며 이전 하위 요청 수에 따라 일련의 독립적인 응답 코드를 포함할 수 있음을 의미합니다.
300	요청한 리소스에는 다양한 대체 응답이 있으며 각 리소스에는 고유한 특정 주소와 브라우저 드라이버 협상 정보가 포함되어 있습니다. 사용자 또는 브라우저는 리디렉션을 위해 기본 주소를 선택할 수 있습니다. HEAD 요청이 아닌 한, 응답에는 사용자나 브라우저가 가장 적절한 리디렉션 주소를 선택할 수 있는 리소스 속성 및 주소 목록이 있는 엔터티가 포함되어야 합니다. 이 엔터티의 형식은 Content-Type에 정의된 형식에 따라 결정됩니다. 브라우저는 응답 형식과 브라우저 자체 기능을 기반으로 가장 적절한 선택을 자동으로 내릴 수 있습니다. 물론 RFC 2616 사양에서는 이러한 자동 선택을 수행하는 방법을 지정하지 않습니다. 서버 자체에 이미 선호하는 피드백 옵션이 있는 경우 위치는 이 피드백의 URI를 나타내야 합니다. 브라우저는 이 위치 값을 자동 리디렉션을 위한 주소로 사용할 수 있습니다. 또한 달리 지정하지 않는 한 이 응답은 캐시 가능합니다.
301	요청한 리소스가 새 위치로 영구적으로 이동되었으며, 향후 이 리소스에 대한 참조는 이 응답에서 반환된 여러 URI 중 하나를 사용해야 합니다. 가능하다면 링크 편집 기능이 있는 클라이언트는 요청된 주소를 서버에서 반환된 주소로 자동 수정해야 합니다. 별도로 지정하지 않는 한 이 응답도 캐시 가능합니다. 새로운 영구 URI는 응답의 위치 필드에 반환되어야 합니다. HEAD 요청이 아닌 이상 응답 엔터티에는 새 URI에 대한 하이퍼링크와 간단한 설명이 포함되어야 합니다. GET 또는 HEAD 요청이 아닌 경우 요청 조건이 그에 따라 변경될 수 있으므로 브라우저는 사용자가 확인하지 않는 한 자동 리디렉션을 금지합니다. 참고: HTTP/1.0 프로토콜을 사용하는 일부 브라우저의 경우 보내는 POST 요청이 301 응답을 받으면 후속 리디렉션 요청은 GET 메서드가 됩니다.
302	이제 요청된 리소스가 다른 URI의 요청에 일시적으로 응답합니다. 이러한 리디렉션은 일시적이므로 클라이언트는 향후 요청을 원래 주소로 계속 보내야 합니다. 이 응답은 Cache-Control 또는 Expires에 지정된 경우에만 캐시할 수 있습니다. 응답의 위치 필드에 새 임시 URI가 반환되어야 합니다. HEAD 요청이 아닌 이상 응답 엔터티에는 새 URI에 대한 하이퍼링크와 간단한 설명이 포함되어야 합니다. GET 또는 HEAD 요청이 아닌 경우 요청 조건이 그에 따라 변경될 수 있으므로 브라우저는 사용자가 확인하지 않는 한 자동 리디렉션을 금지합니다. 참고: RFC이지만 1945 및 RFC 2068 사양에서는 리디렉션 시 클라이언트가 요청 방법을 변경하는 것을 허용하지 않지만 기존의 많은 브라우저에서는 302 응답을 303 응답으로 간주하고 원본과 관계없이 Location에 지정된 URI에 GET 메서드를 사용하여 액세스합니다. 요청 방법. 서버가 클라이언트로부터 기대하는 응답을 명확히 하기 위해 상태 코드 303 및 307이 추가되었습니다.
303	현재 요청에 해당하는 응답은 다른 URI에서 찾을 수 있으며 클라이언트는 해당 리소스에 액세스하려면 GET을 사용해야 합니다. 이 방법은 주로 스크립트에 의해 시작된 POST 요청의 출력이 새 리소스로 리디렉션되도록 하기 위해 존재합니다. 이 새 URI는 원래 리소스에 대한 대체 참조가 아닙니다. 동시에 303 응답은 캐시되지 않습니다. 물론 두 번째 요청(리디렉션)은 캐시될 수 있습니다. 응답의 위치 필드에 새 URI가 반환되어야 합니다. HEAD 요청이 아닌 이상 응답 엔터티에는 새 URI에 대한 하이퍼링크와 간단한 설명이 포함되어야 합니다. 참고: HTTP/1.1 이전의 많은 브라우저는 303 상태를 올바르게 이해하지 못합니다. 이러한 브라우저와의 상호 작용을 고려해야 하는 경우 302 상태 코드로 충분해야 합니다. 왜냐하면 대부분의 브라우저는 위 사양에서 클라이언트가 303 응답을 처리하도록 요구하는 방식과 정확히 동일하게 302 응답을 처리하기 때문입니다.
304	클라이언트가 조건부 GET 요청을 보내고 요청이 허용되었지만 문서의 내용이 변경되지 않은 경우(마지막 액세스 이후 또는 요청 조건에 따라) 서버는 이를 반환해야 합니다. 상태 코드. 304 응답은 메시지 본문을 포함하는 것이 금지되어 있으므로 항상 메시지 헤더 뒤의 첫 번째 빈 줄로 끝납니다.응답에는 다음 헤더 정보가 포함되어야 합니다. 날짜(서버에 시계가 없는 경우 제외). 시계가 없는 서버가 이러한 규칙을 따르는 경우 프록시 서버와 클라이언트는 RFC 2068에 지정된 대로 수신된 응답 헤더 자체에 날짜 필드를 추가할 수 있으며 캐싱 메커니즘은 정상적으로 작동합니다. ETag 및/또는 Content-Location(동일한 요청이 200 응답을 반환해야 하는 경우) Expires, Cache-Control 및/또는 Vary(해당 값이 동일한 변수에 대한 이전의 다른 응답에 해당하는 값과 다를 수 있는 경우) 이 응답 요청이 강력한 캐시 확인을 사용하는 경우 이 응답에는 다른 엔터티 헤더가 포함되어서는 안 됩니다. 그렇지 않으면(예: 조건부 GET 요청이 약한 캐시 확인을 사용함) 이 응답은 다른 엔터티 헤더를 포함하는 것이 금지됩니다. 엔터티 콘텐츠 및 업데이트된 엔터티 헤더 정보. 304 응답이 엔터티가 현재 캐시되지 않았음을 나타내는 경우 캐싱 시스템은 응답을 무시하고 제한 없이 요청을 반복해야 합니다. 캐시 항목 업데이트가 필요한 304 응답이 수신되면 캐시 시스템은 응답에서 업데이트된 모든 필드의 값을 반영하도록 전체 항목을 업데이트해야 합니다.
305	요청된 리소스는 지정된 프록시를 통해 액세스해야 합니다. 지정된 프록시의 URI 정보는 위치 필드에 제공됩니다. 수신자는 이 프록시를 통해 해당 리소스에 액세스하기 위해 별도의 요청을 반복적으로 보내야 합니다. 원본 서버만 305 응답을 설정할 수 있습니다. 참고: RFC 2068은 305 응답이 단일 요청을 리디렉션하기 위한 것이며 원본 서버에 의해서만 설정될 수 있음을 지정하지 않습니다. 이러한 제한 사항을 무시하면 심각한 안전 문제를 초래할 수 있습니다.
306	최신 버전의 사양에서는 306 상태 코드가 더 이상 사용되지 않습니다.
307	이제 요청된 리소스가 다른 URI의 요청에 일시적으로 응답합니다. 이러한 리디렉션은 일시적이므로 클라이언트는 향후 요청을 원래 주소로 계속 보내야 합니다. 이 응답은 Cache-Control 또는 Expires에 지정된 경우에만 캐시할 수 있습니다. 응답의 위치 필드에 새 임시 URI가 반환되어야 합니다. HEAD 요청이 아닌 이상 응답 엔터티에는 새 URI에 대한 하이퍼링크와 간단한 설명이 포함되어야 합니다. 일부 브라우저에서는 307 응답을 인식하지 못하기 때문에 사용자가 새로운 URI를 이해하고 접근 요청을 할 수 있도록 위의 필수 정보를 추가해야 합니다. GET 또는 HEAD가 아닌 경우 요청하면 요청 조건이 그에 따라 변경될 수 있으므로 브라우저는 사용자가 확인하지 않는 한 자동 리디렉션을 금지합니다.
400	1. 의미가 잘못되어 서버에서 현재 요청을 이해할 수 없습니다. 클라이언트는 수정되지 않는 한 이 요청을 다시 제출해서는 안 됩니다. 2. 요청 매개변수가 올바르지 않습니다.
401	현재 요청에는 사용자 확인이 필요합니다. 응답에는 사용자 정보를 요청하는 요청된 리소스에 적합한 WWW-Authenticate 헤더가 포함되어야 합니다. 클라이언트는 적절한 Authorization 헤더가 포함된 요청을 반복적으로 제출할 수 있습니다. 현재 요청에 인증 인증서가 이미 포함된 경우 401 응답은 서버 확인에서 해당 인증서를 거부했음을 나타냅니다. 401 응답에 이전 응답과 동일한 인증 쿼리가 포함되어 있고 브라우저가 인증을 한 번 이상 시도한 경우 브라우저는 응답에 포함된 엔터티 정보를 사용자에게 표시해야 합니다. 이 엔터티 정보에는 관련 진단 정보가 포함될 수 있기 때문입니다. RFC 2617을 참조하세요.
402	이 상태 코드는 향후 필요할 수 있도록 예약되어 있습니다.
403	서버가 요청을 이해했지만 실행을 거부했습니다. 401 응답과 달리 인증은 도움을 제공하지 않으며 요청을 다시 제출해서는 안 됩니다. 이것이 HEAD 요청이 아니고 서버가 요청을 실행할 수 없는 이유를 설명할 수 있기를 원하는 경우 거부 이유를 엔터티에 설명해야 합니다. 물론 클라이언트가 정보를 얻는 것을 원하지 않는 경우 서버는 404 응답을 반환할 수도 있습니다.
404	요청이 실패했습니다. 요청한 리소스를 서버에서 찾을 수 없습니다. 상태가 일시적인지 영구적인지 사용자에게 알려주는 정보는 없습니다. 서버가 상황을 알고 있는 경우 410 상태 코드를 사용하여 일부 내부 구성 메커니즘 문제로 인해 이전 리소스를 영구적으로 사용할 수 없으며 점프 주소가 없음을 알려야 합니다. 404 상태 코드는 서버가 요청이 거부된 이유를 밝히고 싶지 않거나 다른 적절한 응답을 사용할 수 없는 경우 널리 사용됩니다.
405	요청 줄에 지정된 요청 방법을 사용하여 해당 리소스를 요청할 수 없습니다. 응답은 현재 리소스가 수락할 수 있는 요청 메서드 목록을 나타내는 Allow 헤더 정보를 반환해야 합니다. PUT 및 DELETE 메소드는 서버에 리소스를 쓰기 때문에 대부분의 웹 서버는 기본 구성에서 위의 요청 메소드를 지원하거나 허용하지 않으며 이러한 요청에 대해 405 오류가 반환됩니다.
406	요청한 리소스의 콘텐츠 특성이 요청 헤더의 조건을 만족할 수 없어 응답 엔터티를 생성할 수 없습니다. HEAD 요청이 아닌 한, 응답은 사용자나 브라우저가 가장 적절하게 선택할 수 있는 엔터티 속성 및 주소 목록이 포함된 엔터티를 반환해야 합니다. 엔터티의 형식은 Content-Type 헤더에 정의된 미디어 유형에 따라 결정됩니다. 브라우저는 형식과 기능에 따라 최선의 선택을 할 수 있습니다. 그러나 사양에서는 이러한 자동 선택을 위한 기준을 정의하지 않습니다.
407	은 클라이언트가 프록시 서버로 인증해야 한다는 점을 제외하면 401 응답과 유사합니다. 프록시 서버는 ID 쿼리에 대해 프록시 인증을 반환해야 합니다. 클라이언트는 확인을 위해 Proxy-Authorization 헤더를 반환할 수 있습니다. RFC 2617을 참조하세요.
408	요청 시간 초과. 서버가 대기할 준비가 된 시간 내에 클라이언트가 요청 전송을 완료하지 못했습니다. 클라이언트는 변경 사항 없이 언제든지 이 요청을 다시 제출할 수 있습니다.
409	요청한 리소스의 현재 상태와 충돌하여 요청을 완료할 수 없습니다. 이 코드는 사용자가 충돌을 해결하고 새 요청을 다시 제출할 수 있다고 믿는 경우에만 사용해야 합니다. 응답에는 사용자가 충돌의 원인을 발견할 수 있을 만큼 충분한 정보가 포함되어야 합니다. 충돌은 일반적으로 PUT 요청을 처리할 때 발생합니다. 예를 들어 버전 확인을 사용하는 환경에서 PUT에서 제출한 특정 리소스에 대한 수정 요청에 첨부된 버전 정보가 이전(타사) 요청과 충돌하는 경우 서버는 이때 409 오류를 반환해야 합니다. 사용자에게 요청을 완료할 수 없다고 알립니다. 이때 응답 엔터티에는 충돌하는 두 버전 간의 차이점 비교가 포함될 가능성이 높으므로 사용자는 병합 후 새 버전을 다시 제출할 수 있습니다.
410	요청한 리소스를 더 이상 서버에서 사용할 수 없으며 알려진 전달 주소가 없습니다. 그러한 상황은 영구적인 것으로 간주되어야 합니다. 가능하다면 링크 편집 기능이 있는 클라이언트는 사용자의 허가를 받아 이 주소에 대한 모든 참조를 제거해야 합니다. 서버가 조건이 영구적인지 여부를 모르거나 확인할 수 없는 경우 404 상태 코드를 사용해야 합니다. 달리 명시하지 않는 한 이 응답은 캐시 가능합니다. 410 응답의 목적은 주로 웹 사이트 관리자가 웹 사이트를 유지 관리하도록 돕고, 사용자에게 리소스를 더 이상 사용할 수 없음을 알리고, 서버 소유자는 이 리소스를 가리키는 모든 원격 연결도 삭제되기를 희망하는 것입니다. 이러한 유형의 사고는 시간이 제한된 부가 가치 서비스에서 흔히 발생합니다. 마찬가지로 410 응답은 원래 개인에게 속한 리소스를 현재 서버 사이트에서 더 이상 사용할 수 없음을 클라이언트에 알리는 데에도 사용됩니다. 물론 영구적으로 사용할 수 없는 모든 리소스를 '410'으로 표시해야 합니까? 사라졌다', 그리고 이 표시를 얼마나 오랫동안 유지해야 하는지 여부는 전적으로 서버 소유자에게 달려 있습니다.
411	서버가 Content-Length 헤더를 정의하지 않은 채 요청 수락을 거부했습니다. 요청 메시지 본문의 길이를 나타내는 유효한 Content-Length 헤더를 추가한 후 클라이언트는 요청을 다시 제출할 수 있습니다.
412	서버가 요청의 헤더 필드에 제공된 전제 조건 중 하나 이상을 충족하지 못했습니다. 이 상태 코드를 사용하면 클라이언트는 리소스를 검색할 때 요청 메타 정보(요청 헤더 필드 데이터)에 사전 조건을 설정할 수 있으므로 요청 메서드가 예상한 것 이외의 리소스에 적용되는 것을 방지할 수 있습니다.
413	요청에 의해 제출된 엔터티 데이터의 크기가 서버가 처리할 의향이 있거나 처리할 수 있는 범위를 초과했기 때문에 서버가 현재 요청 처리를 거부했습니다. 이 경우 서버는 클라이언트가 이 요청을 계속 보내는 것을 방지하기 위해 연결을 닫을 수 있습니다. 상황이 일시적인 경우 서버는 Retry-After 응답 헤더를 반환하여 나중에 다시 시도할 수 있는 시간을 클라이언트에 알려야 합니다.
414	요청한 URI가 서버가 해석할 수 있는 것보다 길어서 서버가 요청 처리를 거부합니다. 일반적인 상황은 다음과 같습니다. POST 메서드를 사용해야 했던 양식 제출이 GET 메서드가 되어 쿼리 문자열이 너무 길어집니다. 예를 들어 리디렉션 URI "블랙홀"은 각 리디렉션이 이전 URI를 새 URI의 일부로 사용하므로 여러 번의 리디렉션 후 URI가 지나치게 길어집니다. 클라이언트는 일부 서버의 보안 허점을 이용하여 서버를 공격하려고 합니다. 이러한 유형의 서버는 요청된 URI를 읽거나 연산하기 위해 고정된 길이의 버퍼를 사용한다. GET 이후의 매개변수가 특정 값을 초과하면 버퍼 오버플로가 발생하여 임의의 코드가 실행될 수 있다[1]. 이러한 취약점이 없는 서버는 414 상태 코드를 반환해야 합니다.
415	현재 요청 방법 및 요청한 리소스의 경우 요청에 제출된 엔터티가 서버에서 지원하는 형식이 아니므로 요청이 거부됩니다.
416	요청에 Range 요청 헤더가 포함되어 있고 Range에 지정된 데이터 범위가 현재 리소스의 사용 가능한 범위와 일치하지 않고 If-Range 요청 헤더가 요청에 정의되지 않은 경우, 그러면 서버는 416 상태 코드를 반환해야 합니다.Range가 바이트 범위를 사용하는 경우 이 상황은 요청에 의해 지정된 모든 데이터 범위의 첫 번째 바이트 위치가 현재 리소스의 길이를 초과함을 의미합니다. 서버는 또한 416 상태 코드를 반환하는 동안 현재 리소스의 길이를 나타내는 Content-Range 엔터티 헤더를 포함해야 합니다. 이 응답은 Multipart/byteranges를 Content-Type으로 사용하는 것도 금지됩니다.
417	요청 헤더에 지정된 예상 콘텐츠 Expect가 서버에서 충족될 수 없거나, 서버가 프록시 서버이고 현재의 다음 노드에서 Expect의 콘텐츠를 충족할 수 없다는 명백한 증거가 있습니다. 노선. .
421	현재 클라이언트가 위치한 IP 주소에서 서버로의 연결 수가 서버의 최대 허용 범위를 초과했습니다. 일반적으로 여기서 IP 주소는 서버에서 표시되는 클라이언트 주소(예: 사용자의 게이트웨이 또는 프록시 서버 주소)를 나타냅니다. 이 경우 연결 수에는 두 명 이상의 최종 사용자가 포함될 수 있습니다.
422	현재 클라이언트의 IP 주소에서 서버로의 연결 수가 서버의 최대 허용 범위를 초과했습니다. 일반적으로 여기서 IP 주소는 서버에서 표시되는 클라이언트 주소(예: 사용자의 게이트웨이 또는 프록시 서버 주소)를 나타냅니다. 이 경우 연결 수에는 두 명 이상의 최종 사용자가 포함될 수 있습니다.
422	요청 형식은 정확하지만 의미 오류로 인해 응답할 수 없습니다. (RFC 4918 WebDAV) 423 잠김 현재 리소스가 잠겨 있습니다. (RFC 4918 WebDAV)
424	PROPPATCH와 같은 이전 요청의 오류로 인해 현재 요청이 실패했습니다. (RFC 4918 WebDAV)
425	WebDav Advanced Collections 초안에 정의되어 있지만 "WebDAV Sequence Collection Protocol"(RFC 3658)에는 나타나지 않습니다.
426	클라이언트는 TLS/1.0으로 전환해야 합니다. (RFC 2817)
449	Extension by Microsoft는 적절한 작업을 수행한 후 요청을 다시 시도해야 함을 나타냅니다.
500	서버에 예상치 못한 상황이 발생하여 요청 처리를 완료할 수 없습니다. 일반적으로 이 문제는 서버의 프로그램 코드에 오류가 있을 때 발생합니다.
501	서버가 현재 요청에 필요한 기능을 지원하지 않습니다. 서버가 요청된 메서드를 인식하지 못하고 리소스에 대한 요청을 지원할 수 없는 경우.
502	게이트웨이 또는 프록시로 작동하는 서버가 요청을 수행하려고 할 때 업스트림 서버로부터 잘못된 응답을 받았습니다.
503	일시적인 서버 점검이나 과부하로 인해 현재 서버에서 요청을 처리할 수 없습니다. 이 상태는 일시적이며 일정 시간이 지나면 복원됩니다. 지연이 예상되는 경우 응답에는 지연을 나타내는 Retry-After 헤더가 포함될 수 있습니다. 이 Retry-After 메시지가 제공되지 않으면 클라이언트는 500 응답을 처리하는 것과 동일한 방식으로 이를 처리해야 합니다. 참고: 503 상태 코드가 존재한다고 해서 서버가 과부하되었을 때 이를 사용해야 한다는 의미는 아닙니다. 일부 서버는 단순히 클라이언트의 연결을 거부하려고 합니다.
504	게이트웨이나 프록시로 작동하는 서버가 요청을 실행하려고 할 때 업스트림 서버(HTTP, FTP, LDAP 등 URI로 식별되는 서버)로부터 시간 내에 응답을 받지 못합니다. 또는 보조 서버(예: DNS). 참고: 일부 프록시 서버는 DNS 쿼리 시간이 초과되면 400 또는 500 오류를 반환합니다. 서버는 요청에 사용된 HTTP 버전을 지원하지 않거나 지원을 거부합니다. 이는 서버가 클라이언트와 동일한 버전을 사용할 수 없거나 사용할 의사가 없음을 의미합니다. 응답에는 버전이 지원되지 않는 이유와 서버가 지원하는 프로토콜을 설명하는 엔터티가 포함되어야 합니다.
506	투명한 콘텐츠 협상 프로토콜(RFC 2295)에 의해 확장되었으며 서버의 내부 구성 오류를 나타냅니다. 요청된 협상 인수 리소스는 투명한 콘텐츠 협상에서 자체적으로 사용하도록 구성되어 있으므로 협상에서 처리됩니다. 적절한 초점이 아닙니다.
507	서버가 요청을 완료하는 데 필요한 콘텐츠를 저장할 수 없습니다. 이 상태는 일시적인 것으로 간주됩니다. WebDAV (RFC 4918)
509	서버가 대역폭 제한에 도달했습니다. 이는 공식적인 상태 코드는 아니지만 여전히 널리 사용됩니다.
510	자원을 획득하는 데 필요한 전략이 만족스럽지 않습니다. (RFC 2774)

】

위 내용은 프론트엔드 개발자가 꼭 알아야 할 http 프로토콜에 대한 지식의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!