[3장] HTTP 메시지 #4

eunbc · 2023-11-21T14:03:05Z

No description provided.

annahxxl · 2023-11-21T14:04:57Z

http가 인터넷의 배달원이라면, http 메시지는 무언가를 담아 보내는 소포와 같다

메시지의 흐름

메시지가 서버로 향하는 것을 인바운드, 클라이언트로 돌아가는 것을 아웃바운드라고 한다
메시지의 발송자는 수신자의 업스트림이고, 항상 다운스트림으로 흐른다

메시지의 각 부분

요청 메시지

<메서드> <요청 URL> <버전>  # 시작줄
<헤더>                   # 헤더
CRLF
<엔티티 본문>              # 본문

응답 메시지

<버전> <상태 코드> <사유 구절>  # 시작줄
<헤더>                     # 헤더
CRLF
<엔티티 본문>                # 본문

메서드

GET
- 서버에게 리소스를 달라고 요청
HEAD
- GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려준다
- 리소스에 대한 타입을 알아내거나, 응답 상태 코드를 통해 존재하는지 알아보거나, 리소스가 변경되었는지 검사가 필요할 때 사용한다
PUT
- 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체하는 것
POST
- 서버에 입력 데이터를 전송하기 위해 설계
TRACE
- 클라이언트가 어떤 요청을 할 때 방화벽, 프락시, 게이트웨이 등의 애플리케이션을 통과할 수 있는데, 이들에게 http 요청을 수정할 수 있는 기회가 있다
- 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다
- 주로 요청이 의도한 연쇄를 거쳐가는지 검사하는 등 진단을 위해 사용된다
- 요청은 어떠한 엔티티 본문도 보낼 수 없고, 응답의 엔티티 본문에는 서버가 받은 요청이 그대로 들어있다
OPTIONS
- 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있다
DELETE
- 서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청한다

상태 코드

전체 범위	분류
1xx	정보성
2xx	성공
3xx	리다이렉션
4xx	클라이언트 에러
5xx	서버 에러

헤더

일반 헤더 : 클라이언트 서버 양쪽 모두 사용
요청 헤더 : 서버에게 클라이언트가 받고자 하는 데이터의 타입이 무엇인지와 같은 부가 정보
응답 헤더 : 클라이언트에게 정보를 제공하기 위한 자신만의 헤더
엔티티 헤더 : 본문에 대한 헤더
확장 헤더 : 애플리케이션 개발자들에 의해 만들어졌지만 아직 비표준인 헤더

eunbc · 2023-11-21T14:32:46Z

메시지의 흐름

인바운드(서버 방향)와 아웃바운드(클라이언트 방향)
모든 메시지는 업스트림에서 다운스트림으로 흐른다

메시지의 각 부분

시작줄
1. 요청 : <메서드> <요청 URL> <버전>
2. 응답: <버전> <상태코드> <사유 구절>
3. 요청과 응답의 HTTP 버전이 달라도 되나? → 가능하다. 응답을 보낸 애플리케이션이 이해할 수 있는 가장 높은 버전을 나타냄
헤더
1. 이름, 값 쌍의 목록으로 이루어진 추가 정보
2. 본문이 있든 없든 빈 줄(CRLF)로 끝남
본문
1. 이미지, 비디오, HTML 문서, 애플리케이션, 전자우편

메서드

GET : 리소스 요청
HEAD : GET처럼 행동하나, 본문없이 헤더만 리턴. 리소스를 가져오지 않고도 개체 존재 여부, 리소스 타입 확인 가능
PUT : 없으면 만들고, 있으면 교체
POST : 폼에 담긴 입력 데이터 전송
TRACE
OPTIONS : 특정 리소스에 대해 어떤 메소드가 지원되는지 반환
DELETE

상태 코드

100-199 : 정보성 상태 코드
200-299 : 성공 상태 코드
300-399 : 리다이렉션 상태 코드, 클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 그 리소스 내용 대신 다른 대안 응답을 제공
400-499 : 클라이언트 에러 상태 코드
500-599 : 서버 에러 상태 코드

헤더

일반 헤더 : 메시지에 대한 아주 기본적인 정보 제공 (Date, Connection, Via…)
요청 헤더 : 어디에서 누가 요청을 보냈는지에 대한 정보나 클라이언트의 선호나 능력에 대한 정보 (Client-IP, Host, From, User-Agent, Accept, Authorization, Cookie…)
응답 헤더 : 누가 응답을 보내는지, 응답자의 능력에 대한 정보(Age, Server…)
엔터티 헤더 : 엔티티의 내용물에 대한 광범위한 정보(Allow, Location, Content-Length..)
확장 헤더 : 개발자들에 의해 만들어진 비표준 헤더

park0jae · 2023-11-21T17:06:04Z

메시지의 흐름

메시지는 원 서버 방향을 인바운드로 하여 송신된다.

메시지가 원 서버로 향하는 것은 인바운드로 이동하는 것이다.
모든 처리가 끝난 뒤 메시지가 사용자 에이전트로 돌아오는 것은 아웃바운드로 이동하는 것이다.

메시지는 다운스트림으로 흐른다.

HTTP 메시지는 강물과 같이(위에서 아래로) 흐른다.
업스트림 → 다운스트림

메시지의 각 부분 (Start Line, Headers, Body)

요청 메시지(Request Message)

<HTTP Method><Request Target><HTTP Version>
<Headers>
CRLF
<Body>

응답 메시지(Response Message)

<HTTP Version><Status Code><Status Text>
<Headers>
CRLF
<Body>

💡 CRLF : 다음 줄로 넘어가기 위해 커서를 한 줄 아래로 이동 시키고, 가장 앞으로 옮기는 것

💡 사유 구절(reason-phrase) : 숫자로 된 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구

메서드

GET
- 주로 서버에게 리소스 요청을 위해 사용
HEAD
- GET과 유사하지만, 서버 응답으로 헤더만을 돌려주고 본문을 결코 반환되지 않는다.
- 리소스를 가져올 필요 없이 헤더만을 조사할 수 있다.
- 응답의 상태 코드를 통해 개체 존재를 확인할 수 있고, 헤더를 확인하여 리소스의 변경을 검사할 수 있다.
PUT
- 리소스를 대체(수정)하는 메소드
- 요청 메시지에 리소스가 있으면 덮어쓰고, 없으면 새로 생성
POST
- 서버측에 입력 데이터를 전송
TRACE
- 웹 서버 간 통신이 올바르게 이루어지고 있는지 확인하기 위한 목적으로 사용
- 클라이언트가 보낸 HTTP 요청 메시지를 그대로 서버에게 다시 보내라고 하는 것
- 루프백 진단 → 서버가 요청을 받아 들이고, 그 내용을 정확히 처리 하는지를 확인하는 과정
- 이를 통해 클라이언트와 서버 간 통신이 루프백(자기 자신으로 돌아오는)되어 정상적으로 동작하는지 확인 가능
- 클라이언트 요청 패킷이 방화벽, Proxy 서버, Gateway등을 거치며 패킷 변조의 가능성이 존재하는데, TRACE 메소드를 통해 요청했던 패킷 내용과 응답 받은 요청 패킷 내용을 비교하여 변조 유무를 확인할 수 있다.
OPTIONS
- 예비 요청(Preflight)에 사용되는 HTTP 메소드
- 서버의 지원 가능한 HTTP 메소드를 응답 받아 CORS 정책을 검사하기 위한 요청
DELETE
- 리소스의 제거를 요청할 때 사용하는 메소드

상태 코드

분류	내용
1xx Information (조건부 응답)	클라이언트가 서버에 정보를 요청했지만 해당 요청이 여전히 처리 중임을 나타낸다. (해당 상태 코드를 접할 일은 많이 없다고 한다.)
2xx Successful (성공)	우리가 가장 원하는 상태코드.. 서버가 브라우저의 요청을 수신하고 성공적으로 처리했음을 나타낸다.
3xx Redirection (리다이렉션)	서버가 요청된 페이지가 일시적 또는 영구적으로 이동되었음을 클라이언트에게 알릴 때 나타낸다.
4xx Client Error (요청 오류)	클라이언트의 잘못된 요청으로 서버가 이해를 못해 요청을 수행할 수 없음을 의미
5xx Server Error (서버 오류)	클라이언트가 특정 리소스에 대한 액세스를 요청하고 성공했지만, 서버 오류로 인해 서버가 요청을 정상 처리하지 못함을 의미

< 302, 303, 307은 HTTP/1.0과 1.1에서 다르다. >

서버가 POST 요청을 받은 뒤, 클라이언트가 리다이렉션 URL을 받고, GET 요청으로 리다이렉트를 따라가기를 기대하는 상황이라면 ?
- HTTP 1.0 클라이언트: 302 응답을 받고 GET 요청으로 Location 헤더에 있는 URL을 따라감
- HTTP 1.1 클라이언트: 303 응답을 받고 GET 요청으로 Location 헤더에 있는 URL을 따라감 (307은 그대로 POST 메소드 사용할 때)

헤더

일반 헤더
- 클라이언트와 서버 양쪽 모두가 사용 가능하다.
- Connection, Date, MIME-Version … etc
요청 헤더
- 요청 메시지를 위한 헤더
- 클라이언트가 서버에게 받고자 하는 데이터 타입이 무엇인지와 같은 부가 정보를 제공
- Client-IP, From, Host, User-Agent ..
- Accept 헤더
  - 클라이언트가 자신의 선호와 능력을 알려줄 수 있다.
- 조건부 요청 헤더
  - 클라이언트가 요청에 제약을 넣을 때 사용한다.
응답 헤더
- 누가 응답을 보내는지, 응답자의 능력은 어떻게 되는지 제공하며, 클라이언트가 응답을 더 잘 다룰수 있도록 도움을 줌
엔터티 헤더
- 요청과 응답 양쪽 모두 엔터티 헤더를 포함할 수 있다.
- 메시지의 수신자에게 자신이 다루고 있는 것이 무엇인지 말해줌 (Allow , Location …)
- 콘텐츠 헤더
  - 엔터티의 콘텐츠에 대한 구체적인 정보 제공(Content-Length, Content-Location …)

byulcode · 2023-11-21T17:44:18Z

메시지의 각 부분

요청 메시지

요청 라인 : <HTTP 메서드> <요청 URL> <버전>으로 구성
요청 헤더 : 요청 헤더는<필드 이름>: <필드 값> 쌍으로 이루어짐
요청 본문은 필수가 아니지만, 요청 메시지도 본문을 가질 수 있다

응답 메시지

상태 라인 : <버전> <상태코드> <사유 구절> 으로 구성
요청/응답 모두 헤더 이후의 공백 라인(CRLF)는 필수!! => 헤더와 본문 분리

안전한 메서드(Safe Method) vs 멱등성(idempotent)

안전한 메서드(Safe Method)

호출해도 해당 요청이 리소스의 상태를 변경하지 않는다
활용 : 안전하지 않은 메서드가 사용될 때 이를 사용자들에게 알려주는 HTTP 애플리케이션을 만들 수 있도록 한다
GET, HEAD, OPTIONS, TRACE

멱등성(idempotent)

f(f(x)) = f(x)
동일한 연산을 여러 번 적용하더라도 결과가 변하지 않는 특성
활용 : 자동 복구 메커니즘(실패하거나 중단된 트랜잭션을 다시 시도할 때 활용)
GET, HEAD, PUT, DELETE, OPTIONS, TRACE

kimday0326 · 2023-11-22T01:53:01Z

메시지의 흐름

인바운드: 클라이언트 -> 서버 방향
아웃바운드: 서버 -> 클라이언트 방향
업스트림: 발송자
다운스트림: 수신자

메시지의 각 부분

HTTP 메시지는 시작줄, 헤더 블록, 본문 세 부분으로 이루어진다.

시작줄과 헤더는 단순히 줄 단위로 분리된 아스키 문자열이다.
시작줄과 헤더의 각 줄은 CL(Carriage Return) + RF(Line Feed)로 구성된 CRLF 문자열로 구분된다.

요청 메시지 형식
<메서드> <요청 URL> <버전>
<헤더>

<엔터티 본문>

응답 메시지 형식
<버전> <상태코드> <사유 구절>
<헤더>

<엔터티 본문>

요청 메시지와 응답 메시지의 시작줄을 각각 요청줄, 응답줄이라 한다.
상태 코드는 각 응답 메시지의 시작줄에 담겨 반환된다.
버전번호는 자신이 따르는 프로토콜의 버전을 나타낸다.
헤더를 여러 줄로 쪼개기 위해서는 추가 줄 앞에 최소 하나의 스페이스 혹은 탭 문자가 와야한다.
엔터티 본문은 선택적이며 여러 종류의 디지털 데이터를 실어 나를 수 있다.

메서드

안전한 메서드

HTTP 요청의 결과가 서버에 어떤 영향도 미치지 않는 메서드의 집합이다.

메서드의 종류

메서드	설명	본문여부
GET	서버에서 리소스를 가져온다.	없음
HEAD	서버에서 리소스의 헤더만 가져온다.	없음
POST	서버가 처리해야 할 데이터를 보낸다.	있음
PUT	서버에 요청 메시지의 본문을 저장한다.	있음
TRACE	메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다.	없음
OPTIONS	서버가 어떤 메서드를 수행할 수 있는지 확인한다.	없음
DELETE	서버에서 리소스를 제거한다.	없음

확장 메서드

HTTP/1.1 명세에 정의되지 않은 메서드를 확장메서드라 한다.

상태 코드

범위	설명
100-199	HTTP/1.1에서 추가된 정보성 상태코드
200-299	성공 상태코드
300-399	리다이렉션 상태코드
400-499	클라이언트 에러 상태코드
500-599	서버 에러 상태 코드

헤더

일반헤더

메시지에 대한 기본적인 정고를 제공하는 헤더. Connection, Date, Transfer-Encoding 등이 있다. 또한, HTTP/1.0 에서는 로컬 복사본으로 객체를 캐시할 수 있도록 해주는 일반 캐시해더를 도입했다.

요청 헤더

요청 메시지에서만 의미를 갖는 헤더. 일반적인 헤더인 Client-IP, From, Host, User-Agent 외에도 Accept 관련 헤더, 조건부 요청 헤더, 프락시 요청 헤더 등이 있다.

응답 헤더

응답 메시지에서만 의미를 갖는 헤더. Age, Public, Server 와 같은 헤더 외에도 협상 헤더, 응답 보안 헤더 등이 존재한다.

엔터티 헤더

엔터티 본문에 대해 설명하는 헤더들. Allow, Location, 콘텐츠 헤더, 엔터티 캐싱 헤더 등이 있다.

cloudwi · 2023-11-22T03:57:37Z

https://www.notion.so/3-HTTP-dd4846a13eb747779dcd8a107d8fa7e7?pvs=4

메시지의 흐름

인바운드, 아웃바운드, 업스트림, 다운스트립은 메시지의 방향을 의미하는 용어다.

메시지 문법

사유구절

HTTP/1.0 200 NOT OK와 HTTP/1.0 200 OK는 사유 구절이 서로 전혀 달라 보임에도 불구하고 동등하게 성공을 의미하는 것으로 처리되어야 한다.

HTTP 헤더의 집합은 항상 빈 줄로 끝나야 한다.

HEAD

HEAD 메서드는 정확히 GET처럼 행동하지만, 서버는 응답으로 헤더만으르 돌려준다. 엔터디 본문은 결코 반환되지 않는다.

일반 헤더

요청 헤더

응답 헤더

엔터티 헤더

확장 헤더

각 헤더 명을 자동화 할 순 없을까 ?
Authoriztion헤더가 넘어온다면 무조건 토큰이니 까 보아라 처럼

spring이나 각종 프레임워크에서는 디폴트로 어떤 헤더는 무슨 역활을 한다가 정의 되어 있지는 않을까 혹은 약속 되어 있을 것으로 보인다.

국제화 전략으로 볼 수 있을 것 같다.

content type이 대표적인 예시 일 것이다.

KarmaPol · 2023-11-22T04:02:22Z

메시지의 흐름

HTTP 메시지
HTTP 애플리케이션 간에 주고받은 데이터의 블록들

메시지는 원 서버 방향을 인바운드로 하여 송신

인바운드
클라이언트 -> 메시지 -> 원 서버
아웃바운드
서버 -> 메시지 -> 클라이언트

다운스트림으로 흐르는 메시지

메시지는 항상 다운 스트림(클라이언트 -> 서버 -> 클라이언트) 방향으로 흐른다

메시지의 각 부분

시작줄
어떤 메시지인지 서술 (HTTP/1.0 200 OK)
헤더
메시지 속성
본문
데이터를 담음, 아예 없을 수도 있음

시작줄과 헤더는 줄 단위로 분리

메시지 문법

요청

(메서드) (URL) (버전)
(헤더)

(엔티티 본문)

응답

(버전) (상태코드) (사유 구절)
(헤더)

(엔티티 본문)

시작줄

요청줄

서버에서 어떤 동작이 일어나야하는지 - 메서드
HTTP 버전

응답줄

수행 결과 상태 코드, 설명과 HTTP 버전

메서드

서버가 무엇을 해야하는지 설명

GET, POST(메시지 본문 요구), PUT(메시지 본문 요구), DELETE,
HEAD(문서에 대해 헤더만 가져온다), TRACE(메시지 추적), OPTIONS(메서드 수행 여부 확인)
서버마다 메서드 추가 구현 가능 -> 확장 메서드

상태 코드

무엇이 일어났는지 설명

100~ 정보
200~ 성공
300~ 리다이렉션
400~ 클라이언트 에러
500~ 서버 에러

사유 구절

상태 코드와 1대1 대응, 사람이 이해하기 쉬운 버전

헤더

일반 헤더
요청 헤더
응답 헤더
Entity 헤더
본문 크기, 콘텐츠, 리소스 자체를 서술
확장 헤더
명세에 정의되지 않은 새로운 헤더

엔터티 본문

선택적, HTTP의 화물 (디지털 데이터)

HTTP 0.9

요청 - 메서드와 요청 URL, 요청 - 엔터티 만 존재 -> 너무 단순해서 제약생김

메서드

안전한 메서드

서버에 어떠한 작용 X
GET - 서버에 리소스 요청
HEAD - 리소스를 가져오지 않고도 타입, 존재 유무, 변경 유무를 알 수 있음

그 외 메서드

PUT - 서버에 요청 본문을 가지고 새 문서 작성, 이미 존재하다면 교체
POST - 서버에 입력데이터 전송
TRACE - 프락시 등을 거쳤을때 요청/응답이 어떤 영향을 받았는지 검사 (루프백 진단)
OPTIONS - 서버에 어떤 메서드 지원 가능한지 물어본다
DELETE - 서버에서 리소스 삭제, 요청 무시를 허용하므로 삭제 보장 X

확장 메서드

LOCK, MKCOL, COPY, MOVE 등.. 새롭게 구현

eunbc added the 2주차 label Nov 21, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[3장] HTTP 메시지 #4

[3장] HTTP 메시지 #4

eunbc commented Nov 21, 2023

annahxxl commented Nov 21, 2023

eunbc commented Nov 21, 2023 •

edited

Loading

park0jae commented Nov 21, 2023

byulcode commented Nov 21, 2023

kimday0326 commented Nov 22, 2023 •

edited

Loading

cloudwi commented Nov 22, 2023 •

edited

Loading

KarmaPol commented Nov 22, 2023

[3장] HTTP 메시지 #4

[3장] HTTP 메시지 #4

Comments

eunbc commented Nov 21, 2023

annahxxl commented Nov 21, 2023

메시지의 흐름

메시지의 각 부분

메서드

상태 코드

헤더

eunbc commented Nov 21, 2023 • edited Loading

메시지의 흐름

메시지의 각 부분

메서드

상태 코드

헤더

park0jae commented Nov 21, 2023

메시지의 흐름

메시지의 각 부분 (Start Line, Headers, Body)

메서드

상태 코드

헤더

byulcode commented Nov 21, 2023

메시지의 각 부분

안전한 메서드(Safe Method) vs 멱등성(idempotent)

kimday0326 commented Nov 22, 2023 • edited Loading

메시지의 흐름

메시지의 각 부분

메서드

안전한 메서드

메서드의 종류

확장 메서드

상태 코드

헤더

일반헤더

요청 헤더

응답 헤더

엔터티 헤더

cloudwi commented Nov 22, 2023 • edited Loading

메시지의 흐름

메시지 문법

HEAD

KarmaPol commented Nov 22, 2023

메시지의 흐름

메시지는 원 서버 방향을 인바운드로 하여 송신

다운스트림으로 흐르는 메시지

메시지의 각 부분

메시지 문법

요청

응답

시작줄

요청줄

응답줄

메서드

상태 코드

사유 구절

헤더

엔터티 본문

HTTP 0.9

메서드

안전한 메서드

그 외 메서드

확장 메서드

eunbc commented Nov 21, 2023 •

edited

Loading

kimday0326 commented Nov 22, 2023 •

edited

Loading

cloudwi commented Nov 22, 2023 •

edited

Loading