Request-Line
The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
request-line = method SP request-target SP HTTP-version CRLF
- 요청 method는 대소문자 구분
- 세 구성요소에는 공백이 허용되지 않기 때문에 일반적으로 수신자는 공백을 분할하여 request-line을 구성 요소 부분으로 분할한다.
- 불행하게도 일부 사용자 에이전트는 하이퍼 텍스트 참조에서 발견된 공백을 제대로 인코딩하거나 제외하지 못하여 허용되지 않는 문자가 request-target으로 전송된다.
SP : 공백
CRLF : \r\n
request-target
When making a request directly to an origin server, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client MUST send only the absolute path and query components of the target URI as the request-target.
http_URL = "http:" "//" host [":"port][abs_parth]
host = <합법적인 인터넷 호스트 도메인 이름 또는 RFC 1123에서 정의한 방식의 IP 주소(점으로 구분된 형식)>
port = *DIGIT
- 포트 항목이 비어있거나 명시되지 않으면 80으로 간주
request-target = origin-form
/ absolute-form
/ authority-form
/ asterisk-form
- origin-form
origin-form = absolute-path [ "?" query ]
-
absolute-form
프락시에 요청을 할 때, CONNECT 또는 서버 측 OPTIONS 요청을 제외하고 (아래에 자세히 설명된 대로), 클라이언트는 absolute-form을 request-target으로 대상 URI를 보내야 한다.absolute-form = absolute-URI
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 -
authority-form: 도메인 이름 및 옵션 포트(':'가 앞에 붙습니다)로 이루어진 URL의 authority component 입니다.
request-target의 authority-form은 CONNECT 요청에서만 사용된다.
CONNECT developer.mozilla.org:80 HTTP/1.1
- asterisk-form: 서버 전체 OPTIONS 요청에서만 사용된다.
OPTIONS * HTTP/1.1
Header Fields
header-field = field-name ":" OWS field-value OWS
각 헤더 필드는 대소문자를 구분하지 않는 필드 이름 뒤에 콜론(":"), 선택적 앞의 공백(OWS), 필드 값,선택적 뒤의 공백(OWS)으로 구성된다.
Whitespace
이 명세는 OWS(선택적 공백), RWD(필수 공백)및 BWS(불량 공백)의 사용을 나타내는 세가지 규칙을 사용한다.
OWS 규칙 (선택적 공백)
0 이상의 선형 공백 octets이 나타나는 곳에 사용된다.
가독성을 향상시키기 위해 선택적인 공백(OWS)을 선호하는 프로토콜 요소의 경우, 발신자는 단일 SP로서 선택적인 공백(OWS)를 생성해야 한다.(SHOULD)
그렇지 않은경우, 발신자는 내부 메시지 필터링 중에 유효하지 않거나 원하지 않는 프로토콜 요소를 화이트아웃하는 데 필요한 경우를 제외하고 선택적 공백을 생성해서는 안 된다.(SHOULD NOT)
RWS 규칙 (필수 공백)
필드 토큰을 분리하기 위해 하나 이상의 선형 공백 octets이 필요한 경우에 사용된다. 발신자는 단일 SP로서 RWS를 생성해야 한다.(SHOULD)
BWS 규칙 (불량 공백)
오직 역사적인 이유로 선택적인 공백(OWS)을 허락하는 문법에서 사용된다. 발신자는 메시지에서 BWS를 생성해서는 안된다.(MUST NOT) 수신자는 이러한 잘못된 공백을 구문 분석한 후 프로토콜 요소를 해석하기 전에 제거해야 한다.(MUST)
OWS = *( SP / HTAB )
; optional whitespace
RWS = 1*( SP / HTAB )
; required whitespace
BWS = OWS
; "bad" whitespace
Message body Length
메시지 본문의 길이는 다음 중 하나에 의해 결정된다(우선 순위 순서대로):
-
HEAD 요청에 대한 응답과 1xx(Informational), 204(No Content) 또는 304(Not Modified)
메시지에 있는 헤더 필드에 관계 없이 헤더 필드 다음의 첫 번째 빈 줄로 항상 종료되므로 메시지 본문을 포함할 수 없다. -
CONNECT 요청에 대한 2xx(Successful)
헤더 필드를 마치는 빈 줄 직후 커넥션은 터널이 됨을 내포한다. 클라이언트는 이러한 메시지에 수신된 Content-Length 또는 Transfer-Encoding 헤더 필드를 반드시 무시해야 한다. (MUST) -
Transfer-Encoding 헤더 필드가 있고 청크 전송 코딩(Section 4.1)이 최종 인코딩인 경우, 전송 코딩이 데이터가 완료되었음을 나타낼 때까지 청크 데이터를 읽고 디코딩 하여 메시지 본문 길이를 결정한다.
status code
200 ok
요청이 성공적으로 되었습니다. 성공의 의미는 HTTP 메소드에 따라 달라집니다:
GET: 리소스를 불러와서 메시지 바디에 전송되었습니다.
HEAD: 개체 해더가 메시지 바디에 있습니다.
PUT 또는 POST: 수행 결과에 대한 리소스가 메시지 바디에 전송되었습니다.
TRACE: 메시지 바디는 서버에서 수신한 요청 메시지를 포함하고 있습니다.
201 Created
요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었습니다. 이 응답은 일반적으로 POST 요청 또는 일부 PUT 요청 이후에 따라옵니다.
204 No Content
204 응답은 메시지 본문을 포함하지 않아야 하므로 항상 헤더 필드 다음의 first empty line로 종료됩니다.
400 Bad Request
이 응답은 잘못된 문법으로 인하여 서버가 요청을 이해할 수 없음을 의미합니다.
404 Not Found
서버는 요청받은 리소스를 찾을 수 없습니다. 브라우저에서는 알려지지 않은 URL을 의미합니다. 이것은 API에서 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수도 있습니다.
content-length 필요(body 올수도 있음)
500 Internal Server Error
서버에서 요청을 이행하지 못하게 하는 예기치 않은 조건이 발생했습니다.
204에 content-length 보내면안된다
content-length 0이면 보내지않기
