HTTP 개요

 

 

 

HTTP message

HTTP 메시지는 클라이언트 요구, 서버의 응답으로 구성됨

 

Request : HTTP/1.1 messages

Response : HTTP/1.1 messages

 

요구 및 응답 메시지는 엔티티를 전송하기 위해 RFC 822의 일반적인 메시지 형식을 사용

헤더 필드의 끝을 표시하는 빈라인(CRLF 이전에 아무것도 없는 라인) 

 

 

HTTP Request 메시지 필드 구성

Method URI HTTP-Version

Message Header

CRLF 

Message Body

CRLF

 

HTTP Response 메시지 필드 구성

Method Status-Code Status문자열

Message Header

CRLF 

Message Body

CRLF

 

 

안정적인 동작을 위해 서버는 규악 스트림을 읽는 도중

메시지 처음 Request Line 이 있어야할곳에 빈라인(CRLF)을 수신하면 이를 무시

 

HTTP/1.1 클라이언트는 여분의 CRLF로 요구를 시작하거나 따라서는 안된다.

 

 

 

---

Method

---

거의 GET, POST만 쓴다.

 

GET, HEAD method는 조회 이외의 작업을 수행하는 중요성을 가질수없다는 관례가 확립됨

GET,HEAD method는 안전한 것으로 간주

 

 

Method	설명
GET	자원에 대한 조회
POST	확장된형태. 메세지 바디 포함
PUT	엔티티를 제공된 Request URI에 저장하도록 요구. 특정 자원을 서버에 전송하는 경우.
DELETE	Request URI가 식별하는 자원을 삭제하도록 원서버에 요구
OPTION	서버가 지원하는 메서드 확인
HEAD	자원에 대한 조회. 그러나 메세지 바디를 포함하지 않음. 응답 메시지 헤더만 확인하는 경우.
TRACE	요청 헤더를 그대로 돌려줌

 

 

 

GET

 

 

POST

 

 

 

PUT

엔티티를 제공된 Request URI에 저장하도록 요구

URI가 이미 존재할 경우 이는 엔티티의 변경된 버전으로 간주해야함

없으면 새로운 자원으로 규정할 수 있을시 자원을 생성

 

새로운 자원이 생성되었으면 원서버는 사용자 에이전트에게 201(Created) 응답을 알림

기존 자원이 변경되었다면 200이나 204(No Content) 발송하여

요구를 성공적으로 완료하였음을 표시

 

자원을 생성하거나 변경할 수 없는 경우 적절한 에러 응답을 발송

 

POST와 PUT의 차이점

Request URI의 다른 의미에 반영

POST의 URI는 동봉된 엔티티를 처리할 자원을 식별

해당 자원은 프로세스, 다른규약으로의 게이트웨이, 또는 주석을 접수하는 별도의 엔티티일 수 있다.

PUT의 URI는 요구에 포함된 엔티티를 식별

 

만약 서버가 해당 요구를 다른 URI에 적용하고자 한다면 서버는 301(Moved Permanently)응답을 반드시 발송해야한다.

그래서 사용자 에이전트가 해당 요구의 방향을 재설정할것인지 결정할 수 있게한다.

 

PUT 요구는 메시지 전송 필요 조건을 반드시 따라야한다.(RFC2616 8.2절 참고)

 

 

 

DELETE

Request URI가 식별하는 자원을 삭제하도록 원서버에 요구

이 메서드는 원서버에서 사용자 개입이나 다른 방법에 의해 무시될 수 있음

클라이언트는 성공응답을 받아도 삭제가 실제로 이루어졌는지는 보장받을 수 없음

그러나 서버는 요구 접수한 시점에서 자원을 삭제하거나 접근할 수 없는 위치로 이동할 의사가 없는 한 성공 메시지를 표시하면 안됨

 

성공응답의 상태코드로는 200(OK), 202(Accepted), 204(No Content)이다.

 

 

OPTION

Request URI에 의하여 식별되는 Request/Response chain 에서 사용할 수 있는 통신 선택 사항에 관한 정보 요구 표시

 

 

HEAD

 

 

 

TRACE

요구 메시지의 원격지, 애플리케이션계층 루프백(loop back)을 호출하는데 사용

 

응답의 최종 수신측은 클라이언트에게 되돌려진 메시지를 200 응답의 Entity Body로 수신해야한다.

마지막 수신측증 메시지의 Max-Forwards 0값을 수신하는 원서버, 첫 프락시 또는 게이트웨이이다.

 

TRACE 요구는 절대 엔티티를 포함해서는 안된다.

 

TRACE는 클라이언트가 Request chain의 다른 끝 쪽에 무엇이 수신되는가 알수잇게함

그 데이터를 시험 또는 진단 정보로 사용

Via 헤더 필드의 값은 Request chain의 추적 역할을 수행하기 때문에 특히 주목할만하다

 

Max-Forwards 헤더 필드를 사용하면 클라이언트가 Request chain 길이를 제안할 수 있다.

이는 무한 루프에서 메시지를 전달하는 프락시고리를 테스트 하는데 유용하다.

 

성공적이면 응답은 message/http의 Content-Type을 가진 Entity Body의 전체 요구 메시지를 포함할 수 있어야 한다.

 

이러한 method에 대한 응답을 절대 캐시해서는 안됨

 

 

 

 

---

Status Code

---

 

 

1xx : 정보를 알려줌

2xx : 성공을 알림

3xx : 방향 재설정

4xx : 클라이언트측 에러

5xx : 서버측 에러

 

 

 

 

 

---

Message Body

---

 

요구 또는 응답과 관련된 Entity Body를 전송하는데 사용

Message Body는 선택사항이다.

 

Message Body와 Entity Body 차이

Transfer-Encoding 헤더 필드에 설명된 전송 코딩이 적용되었을때에만 Entity-Body오 다르다

 

안전하고 적절한 메시지 전송을 위해 애플리케이션이 적용한 전송 코딩 방식을 표시하기 위해 반드시

Transfer-Encoding 을 사용

Transfer-Encoding 은 메시지의 특성이다. 엔티티의 특성이 아님

Transfer-Encoding 은 요구/응답에 따라 애플리케이션이 추가 또는 삭제할 수 있다.

 

 

Message Body가 포함되었는지 여부확인

Request 

Content-Length 또는 Transfer-Encoding 헤더필드를 포함함으로써 표시

Message Body는 요구 method가 Entity Body를 허용할 때만 요구 메시지에 포함할수도있음

Response

요구 method 및 응답 상태 코드에 달려있음

 

 

응답상태에 따른 Message Body 포함여부

모든 1xx(Informational), 204(No Content), 304(Not Modified) 응답은 Message Body를 절대 포함해서는 안된다.

다른 모든 응답은 길이가 0이라해도 Message Body를 포함한다.

 

또한 HEAD 요구 method에 대한 모든 응답은 Entity Header 필드가 포함한것처럼 보여도

Message Body를 포함해서는 절대 안됨

 

 

메시지 길이 표시 규정

1. 1xx, 204, 304응답 메시지, HEAD요구에 대한 모든 응답은 헤더 필드 다음의 첫 빈 라인으로 항상 종료됨

2. Transfer-Encoding 헤더 필드가 존재하고 chunked 전송 코딩이 적용되었음을 표시하고 있으면 길이는 chunked 인코딩에 의해 규정됨

3. Content-Length 헤더 필드가 존재하면 그 바이트 단위의 값이 Message Body 길이임

4. 메시지가 multipart/byteranges를 사용하고 있으면 이것이 길이를 규정

이 미디어 형식은 송신자가 수신측이 그것을 분석할 수 있다는 것을 알 수 없을때에는 사용하면 안됨

5. HTTP/1.1 요구는 서버가 HTTP/1.1을 따르는것을 알기전엔 반드시 Content-Length필드를 포함.

 

요구가 Message Body를 포함하고 있고 Content-Length가 주어지지 않으면 서버는 메시지 길이를 결정할 수 없을때 400(Bad Request)을 응답으로 보낸다.

유효한 Content-Length 수신을 기다리고자 할때는 411(Length Required) 메시지를 반송한다.

 

엔티티를 수신하는 모든 HTTP/1.1 애플리케이션은 반드시 chunked 전송 코딩을 허용해야한다.

이렇게 해야 메시지 길이를 미리 결정할 수 없을때 이 메커니즘이 사용될 수 있다.

 

메시지는 Content-Length 헤더 필드와 chunked 전송 코딩을 모두 포함하면 안된다.

둘다 수신하면 Content-Length는 반드시 무시한다.

 

Message Body의 10진수 숫자크기와 Content-Length 필드값은 정확히 일치해야한다.

HTTP/1.1 사용자 에이전트는 유효하지 않은 길이를 수신했거나 탐지했을때 사용자에게 이를 알려야한다.

 

 

 

 

 

 

 

---

HTTP Header

---

 

헤더의 정렬 순서는 상관없다

필드이름의 대소문자는 구분하지 않는다.

각 헤더필드는 CRLF로 이어나간다.

 

형식

필드이름 : 필드값 CRLF

 

헤더 종류

Request Header, Response Header, Entity Header

 

헤더순서 바람직한 관행

General Header 필드

Request Header나 Response-Header 필드

Entity Header 필드의 순서를 따름

 

 

프록시는 메시지를 전송할때 필드값의 순서를 변경하면 안된다.

 

Request Header 필드는 반드시 모든 HTTP/1.1 요구를 따라야 한다.

 

 

https://imar.tistory.com/54

 

 

---

---

HTTP-Version

---

 

HTTP 규약 버전명시.

번호체계 : <주요한 변경>.<사소한변경>

각 필드는 정수값으로 표현됨

=>HTTP/2.4은 HTTP/2.13 보다 이전 버전임

표기예시) HTTP/1.1

 

 

HTTP 버전값은 해당 애플리케이션이 최소한의 조건으로 상호동작을 지원하는 최고 버전의 HTTP 버전값이다.

 

 

---

URI

---

 

URI (Uniform Resource Identifier)

URL(Uniform Resource L), URN(Uniform Resource Name) 등 여러 이름으로 불린다.

이름, 위치 등으로 자원을 식별해 주는 정형화된 문자열을 말한다.

 

형태

절대적으로 표현할수도있고

URI의 상대적인 형태로도 표현할수있음

 

둘의 구분은 절대적URI는 항상 콜론이 뒤따르므로 구분가능

 

HTTP 규약에서 URI 길이는 제한을 두지 않는다.

하지만 255 byte 이상의 URI 길이를  사용하면 몇몇 클라이언트나 프록시구현방식은

이를 지원하지 못할수있으므로 주의

 

 

HTTP url

형식 : http://host주소:port주소

host주소는 도메인 or IP주소

URL에서 IP주소사용은 피해야한다.

 

포트 항목이 비어있거나 명시되지 않으면 80으로 간주

TCP연결요구를 기다리는 해당 호스트 서버의 해당 포트에 식별된 자원이 위치하고있음

 

 

URI 비교

URI 비교시 전체 URI에 대하여 대소문자를 구별하는 8진수 대 8진수 비교 방법을 사용(octet-by-octet comparison)

 

예외사항

비어있거나 명시되지 않은 기본 포트는 80번으로 정의

호스트 이름의 비교에 반드시 대소문자를 구별하지 않음

scheme 이름의 비교는 반드시 대소문자를 구별하지 않음

비어있는 

 

예를 들어 다음의 세 URI 는 동일하다.

http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html

 

 

---

날짜/시간형식

---

 

헤더필드의 HTTP-날짜 값의 표기는 RFC 1123 형식을 따라야한다.

모든 HTTP 날짜/시간 표시는 반드시 GMT(그린이치 표준 시간)을 따른다.

 

반드시 메시지에 표기할 필요는 없다.

 

날짜값 수신처는 SMTP NNTP등의 비 HTTP 애플리케이션이 발송한 날짜 값을 수신하도록 조치할것을 권장

 

 

 

---

Delta Seconds

---

HTTP헤더

메시지가 수신된 이후의 시간을 10진법의 정수로 초를 명시할 수 있음

delta-seconds : 정수

 

 

 

---

Media type

---

 

 

Multipart Type

MIME은 많은 multipart 형식을 제공한다.

여러 엔티티를 단일 메시지 본문 내에 포함시킬 수 있게함

 

 

형식

multipart/form-data

POST 요구 method로 처리하기에 적합한 폼 데이터를 전송하기 위해 특별히 규정되었다.

 

미디어 형식 표시값의 일부로서 경계 파라미터를 포함함

Body-Part 간 줄바꿈 표시는 반드시 CRLF만을 사용

 

MIME과는 달리 모든 multipart 메시지의 맺음말은 반드시 비어있어야한다.

HTTP 애플리케이션은 맺음말을 절대로 전송해서는 안된다.(원래 multipart가 맺음말을 포함하고있으면 제거)

 

multipart의 Body-Part는 해당 부분의 중대한 영향을 끼치는 헤더필드를 포함할 수 있다.

Content-Location 헤더 필드는 URL로 확인할 수 있는 엔티티의 Body-Part에 포함되어야 한다.

 

HTTP 사용자 에이전트는 MIME 사용자 에이전트가 multipart 유형을 수신했을때 처리하는 방식과 유사하거나 동일한 방식을 따라야한다.

 

 

 

---