HTTP 메시지 : HTTP 애플리케이션 간에 주고 받는 데이터 블록(텍스트 메타 정보, 데이터, 클라이언트, 서버, 프락시 사이를 흐름)들을 의미
인바운드와 아웃바운드
트랜잭션의 방향을 표현하기 위해 사용하는 개념, 서버 입장의 개념
- 인바운드
- 메시지가 서버로 향하는 것
- 아웃바운드
- 메시지가 클라이언트로 돌아오는 것
3-2. 메시지의 각 부분
다운 스트림
HTTP는 강물과 같이 흐르고, 요청/응답 메시지 상관없이 모든 메시지는 다운스트림으로 흐른다.
메시지 각 부분
시작줄 : 어떤 메시지인지 서술
요청 메시지
메서드 요청 url 버전
응답 메시지
버전 상태 코드 사유 구절
200 OK, 200 NOT OK
헤더
속성
시작줄과 헤더는 줄 단위로 분리된 아스키 문자열
각 줄은 두 글자의 줄바꿈 문자열(CRLF)로 끝남
CR : Carriage Return (\\r) LF : Line Feed (\\n) CR : 현재 커서를 줄 올림 없이 가장 앞으로 옮기는 동작 LF : 커서는 그 자리에 그대로 둔 상황에서 종이만 한 줄 올려 줄을 바꾸는 동작
본문
데이터를 담거나 아예 없을 수 있음
💡 메시지 헤더는 반드시 CRLF로 끝나야 한다. 그런데 이를 지키지 않는 경우도 있으므로 (오래되거나, 잘못된 경우)클라이언트와 서버는 CRLF가 없는 메시지도 받을 수 있어야 한다. → 잘못 오면 안됨!!!
메서드
메서드 설명 본문 여부
GET
서버에서 문서 가져옴
x
HEAD
서버에서 어떤 문서의 헤더만 가져옴
x
POST
서버가 처리해야 할 데이터를 전송함
o
PUT
서버에 요청 메시지의 본문을 저장함
o
TRACE
메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적함
x
OPTIONS
서버가 어떤 메서드를 수행할 수 있는지 확인함
x
DELETE
서버에서 문서를 제거함
x
상태 코드
서버가 클라이언트의 요청에 대한 결과를 알려주는 세자리 숫자를 의미한다.
상태 코드는 프로그램이 에러를 처리하기 쉽게 해준다.
- 상태 코드 종류전체 범위 정의된 범위 분류
100-199
100-101
정보
200-299
200-206
성공
300-399
30-305
리다이렉션
400-499
400-415
클라이언트 에러
500-599
500-505
서버 에러
200 : OK, 성공, 요청한 모든 데이터는 응답 본문에 들어있음
401 : Unauthorized, 사용자 이름과 비밀번호를 입력
404 : Not Found, 서버는 요청한 URL에 해당하는 리소스를 찾지 못함
사유 구절
상태코드의 사람이 이해하기 쉬운 버전
HTTP/1.0 200 OK 에서 OK가 위치한 부분을 의미
3-3. 메서드
서버는 모든 메서드를 사용해 구현하지 않는다(부스타가 GET, POST만 사용하는 것처럼)
→ 사용자가 악용할 수 있는 문제가 발생할 수 있음
1. 안전한 메서드
GET, HEAD 메서드가 해당되고, 이 메서드를 사용한 HTTP 요청을 보내도 서버에 어떠한 영향(작용)도 미치지 않는다.
안전한 메서드를 알면 안전하지 않은 메서드를 알 수 있고, 안전하지 않은 메서드를 사용할 때 서버에서 어떤 일이 일어날 수 있음을 알려주는 경고 메시지를 만들 수 있다.
2. GET
가장 흔히 쓰이는 메서드로, 주로 서버에게 리소스를 달라고 요청하기 위해 사용한다.
3. HEAD
정확히 GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려주는 메서드이다.
HEAD로 반환되는 헤더 = GET으로 반환되는 헤더
HTTP/1.1 준수를 위해서는 HEAD 메서드가 반드시 구현되어 있어야 한다.
HEAD 메서드를 통해 얻을 수 있는 것들
리소스를 가져오지 않고도 리소스가 무엇인지(타입)를 알아낼 수 있음
응답 상태코드로 리소스 존재 여부 확인 가능
응답 헤더를 확인해 리소스가 변경되었는지 검사 가능
4. PUT
요청 body를 이용해 요청 URL의 이름대로 새 문서를 만들거나
이미 URL이 존재한다면 body를 사용해 교체하는 것을 의미
→ PUT은 콘텐츠를 변경할 수 있게 해주기 때문에 많은 웹 서버가 PUT을 수행하기 전에 로그인으로 사용자 식별을 선행할 것이다.
5. POST
서버에 입력 데이터를 전송하기 위해 설계된 메서드이다. 본문에 담긴 데이터가 서버로 전송되고, 서버는 이를 모아서 필요로 하는 곳으로 보낸다.
6. TRACE
주로 진단을 위해 사용되는 메서드이다. 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다(요청은 방화벽, 프락시, 게이트웨이 등 애플리케이션에 의해 수정될 수 있기 때문)
TRACE 요청
본문에 어떤 엔티티도 넣어서 보낼 수 없음
요청 전송의 마지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답
클라이언트는 자신과 목적지 서버 사이에 있는 모든 HTTP 요청/응답 연쇄를 따라가며 자신이 보낸 메시지가 망가졌거나 수정되었는지, 수정되었다면 어떻게 수정되었는지 확인할 수 있음
용도
요청이 의도한 요청/응답 연쇄를 거쳐가는지 확인
다른 애플리케이션이 요청에 어떤 영향을 미치는지 확인
주의사항
애플리케이션 별로 TRACE 요청을 어떻게 처리하는지 방법이 다르다
7. OPTIONS
웹 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어보는 메서드이다.
여러 리소스에 실제로 접근하지 않고도 그것들을 어떻게 접근하는 것이 최선인지 확인할 수 있는 수단을 클라이언트 애플리케이션에게 제공한다.
8. DELETE
서버에게 요청 URL로 지정한 리소스 삭제를 요청하는 메서드이다.
3-4. 상태 코드
1. 100-101 : 정보성 상태 코드상태 코드 사유 구절 의미
100
Continue
요청의 시작 부분 일부가 받아들여졌고, 클라이언트는 나머지를 계속 이어서 전송해야함을 의미
101
Switching Protocols
서버가 프로토콜을 변경했음을 의미
클라이언트의 요청이 서버에 도달했고 서버가 프로세스를 진행하고 있다는 의미
클라이언트와 100 ContinueExpect 요청 헤더를 추가해서 요청해야 한다
서버가 다루거나 사용할 수 없는 큰 엔티티를 서버에게 보내지 않으려는 목적으로만 사용해야 한다
서버와 100 Continue
서버가 100-continue 값이 담긴 Expect 헤더가 포함된 요청을 받는다면, 100 continue 응답 혹은 에러코드로 응답해야 한다.
2. 200-206 : 성공 상태 코드
요청이 성공적으로 처리되었을 때의 응답 상태 코드
상태 코드
사유 구절
의미
200
OK
요청이 정상 처리 됐고, 엔티티 본문은 요청된 리소스를 포함한다.
201
Created
서버 개체 생성 요청의 성공 응답.
202
Accepted
요청은 받아들여졌으나 서버는 아직 그에 대한 어떤 동작도 수행하지 않았음.
203
Non-Authoritative Information
중개자가 리소스의 사본을 갖고 있었지만, 리소스에 대한 헤더를 검증하지 못한 경우의 상태 코드.
204
No Content
응답에 헤더와 상태줄을 포함하지만, 엔티티 본문은 포함하지 않는다는 상태 코드. 주로 웹 브라우저를 새 문서로 이동시키지 않고 갱신할 때 사용한다.
205
Reset Content
브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우라고 말하는 상태콛. 주로 브라우저를 위해 사용된다.
206
Partial Content
부분 혹은 범위 요청이 성공했다는 것을 알리는 상태 코드. Content-Rage, Date는 반드시 포함해야 하며 Etag, Content-Location 중 하나도 반드시 포함해야 한다.
3. 300 - 307 : 리다이렉션 상태 코드
리다이렉션 상태 코드는 클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 다른 대안을 제공한다.
리다이렉션 상태 코드만약 리소스가 옮겨졌다면, 클라이언트에게 리소스가 옮겨졌으며 어디서 찾을 수 있는지 알려주기 위해 리다이렉션 상태 코드와 선택적으로 Location 헤더를 보낼 수 있다.
상태 코드
사유 구절
의미
300
Multiple Choices
클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청한 경우, 그 리소스의 목록과 함께 반환.
301
Moved Permanently
요청한 URL이 옮겨졌을 때 사용. 응답은 Location 헤더에 현재 리소스가 존재하고 있는 url을 포함해야 한다.
302
Found
요청한 URL이 옮겨졌을 때 사용. 응답에서의 Location 헤더로 주어진 url은 리소스를 임시로 가리키고 있기에 이후의 요청은 원래 url을 사용해야 한다.
303
See Other
클라이언트에게 리소스를 다른 url에서 가져와야 한다고 말해주는 용도. 주 목적은 POST 요청에 대한 응답으로 클라이언트에게 리소스의 위치를 알려주는 용도이다.
304
Not Modified
수정되지 않은 리소스에 대해 수정되지 않았음을 알려주는 상태 코드.
305
Use Proxy
리소스가 반드시 프락시를 통해서 접근되어야 함을 나타내기 위해 사용.
306
사용되지 않음
307
Temporary Redirect
302와 설명 동일
302, 303, 307의 유사한 설명HTTP/1.1 위 리다이렉션을 303 상태코드로 진행하고, 307은 일시적인 리다이렉트를 위해 사용함.
→ 서버는 리다이렉트 응답에 들어갈 가장 적절한 리다이렉트 상태 코드를 선택하기 위해 클라이언트의 HTTP의 버전을 검사해야 한다.
HTTP/1.0 에서는 POST 요청에 대한 리소스의 위치를 302 코드로 전송(서버는 클라이언트가 리다이렉션 URL에 대한 GET 요청으로 리다이렉트를 따라가길 기대함)
4. 400 - 417 : 클라이언트 에러 상태 코드상태 코드 사유 구절 의미
상태 코드
사유 구절
의미
400
Bad Request
클라이언트가 잘못된 요청 보냄
401
Unauthorized
리소스를 얻기 전에 스스로 인증하라고 요구하는 상태코드
402
Payment Required
현재 쓰이지 않는 상태 코드.
403
Forbidden
요청이 서버에 의해 거부되었음을 알려주기 위해 사용됨
404
Not Found
서버가 요청한 URL을 찾을 수 없음을 알려주기 위해 사용.
405
Method Not Allowed
URL에 지원하지 않은 메서드로 요청을 받았을 때 사용. 응답 헤더에 Allow 헤더가 있어야 함
406
Not Acceptable
주어진 url에 대한 리소스 중 클라이언트가 받아들일 수 있는게 없을 때 사용.
407
Proxy Authentication Required
401과 동일하지만, 프락시 서버에 인증을 해야하는 경우에 사용.
408
Request Timeout
클라이언트 요청을 완수하기에 시간이 너무 많이 걸릴 때 서버는 이 상태코드를 보내고 연결을 끝낼 수 있음
409
Conflict
요청이 리소스에 대해 일으킬 수 있는 몇몇 충돌을 지칭하기 위해 사용.
410
Gone
404와 비슷하지만 서버 관리자가 클라이언트에게 기조에 있었던 리소스가 제거된 경우를 알려주기 위해 사용.
411
Length Required
서버가 요청 헤더에 Content-Length 헤더가 있어야 함을 요구할 때 사용.
412
Precondition Failed
클라이언트가 조건부 요청을 했는데 그중 하나가 실패했을 때 사용.
413
Request Entity Too Long
처리 한계를 넘은 요청을 클라이언트가 전송시 사용.
414
Request URI Too Long
처리 한계를 넘는 길이의 요청 URL이 포함된 요청을 클라이언트가 보냈을 때 사용.
415
Unsupported Media Type
서버가 이해하거나 지원하지 못하는 내용 유형의 엔티티를 클라이언트가 보냈을 ㅅ때 사용
416
Requested Range Not Satisfiable
리소스의 특정 범위를 요청했는데 그 범위가 잘못되거나 맞지 않을 때 사용.
417
Expectation Failed
요청에 포함된 Expect 요청 헤더에 서버가 만족시킬 수 없는 기대가 담겨있는 경우 사용.
5. 500 - 505 : 서버 에러 상태 코드상태 코드 사유 구절 의미
클라이언트가 올바른 요청을 보냈음에도 서버 자체에서 에러가 발생하는 경우가 있는데, 그때 사용하는 상태 코드이다.
상태 코드
사유 구절
의미
500
Internal Server Error
서버가 요청을 처리할 수 없게 만드는 에러를 만났을 때 사용
501
Not Implemented
클라이언트가 서버의 능력을 넘는 요청을 했을 때 사용(서버가 지원하지 않는 메서드 사용) → Method Not Allowed 아닌가?
502
Bad Gateway
자신의 부모 게이트웨이에 접속하는 것이 불가능할 때 사용하는 코드
503
Service Unavailable
현재는 서버가 요청을 처리해 줄 수 없지만, 나중에는 가능함을 의미하는 코드. Retry-After헤더를 응답에 포함해 전송
504
Gateway Timeout
상태코드 408과 비슷함. 게이트웨이나 프락시에서 타임아웃이 발생해서 온 응답이라는 것에서 다름.
505
HTTP Version Not Supported
서버가 지원할 수 없거나 지원하지 않으려고 하는 버전의 프로토콜로 된 요청을 받았을 때 사용.
3-5. 헤더
쿠키랑 인증키만 기억하면 됨!!!
일반 헤더
클라이언트와 서버 양쪽 모두가 사용하는 헤더이고, 메시지에 대한 아주 기본적인 정보를 제공한다. 메시지 종류에 상관없이 유용한 정보를 제공한다.
헤더
설명
Connection
요청/응답 연결에 대한 옵션 정할 수 있게 해줌
Date
메시지가 언제 만들어졌는지에 대한 날짜와 시간 제공
MIME-Version
발송자가 사용한 MIME의 버전을 알려줌
Trailer chunked transfer
인코딩으로 인코딩된 메시지의 끝 부분에 위치한 헤더들의 목록을 나열
Transfer-Encoding
수신자에게 안전한 전송을 위해 메시지에 어떤 인코딩이 적용되었는지 말해줌
Upgrade
발송자가 ‘업그레이드’하길 원하는 새 버전이나 프로토콜을 알려줌
Via
이 메시지가 어떤 중개자(프락시, 게이트웨이)를 거쳐 왔는지 보여줌
일반 캐시 헤더
HTTP/1.0은 매번 서버로부터 객체를 가져오는 대신 로컬 복사본으로 캐시할 수 있는 최초의 헤더를 도입함.
헤더
설명
Cache-Control
메시지와 함께 캐시 지시자를 전달하기 위해 사용함
Pragma
메시지와 함께 지시자를 전달하는 또 다른 방법. 캐시에 국한되지 않음. 엄밀히 말하면 요청 헤더. deperecated 될 예정.
요청 헤더
요청 메시지에서만 의미를 갖는 헤더이다.
헤더
설명
Client-IP
클라이언트가 실행된 컴퓨터 IP 제공
From
클라이언트 사용자의 메일 주소 제공
Host
요청의 대상이 되는 서버의 호스트 명과 포트 제공
Referer
현재의 요청 URI가 들어있던 문서의 URL 제공 → URL의 URL?
UA-Color
클라이언트 기기 디스플레이의 색상 능력 정보 제공
UA-CPU
클라이언트 CPU 종류나 제조사 알려줌
UA-Disp
클라이언트 디스플레이 능력에 대한 정보 제공
UA-OS
클라이언트 기기에서 동작 중인 os 이름과 버전 제공
UA-Pixels
클라이언트 기기 디스플에이에 대한 픽셀 정보 제공
User-Agent
요청을 보낸 애플리케이션 이름 알려줌
Accept 관련 헤더
클라이언트는 Accept 관련 헤더를 이용해 서버에게 자신의 선호와 능력을 알려줄 수 있다. 이는 클라이언트와 서버 모두에 유용한 정보이고, 클라이언트는 그들이 원하는 것을 얻을 수 있고, 서버는 클라이언트가 사용할 수 없는 것을 전송하는데 시간과 대역폭을 낭비하지 않아도 된다.
헤더
설명
Accept
서버가 보내도 되는 미디어 종류
Accept-Charset
서버가 보내도 되는 문자집합
Accept-Encoding
서버가 보내도 되는 인코딩
Accept-Language
서버가 보내도 되는 언어
TE
서버가 보내도 되는 확장 전송 코딩
조건부 요청 헤더
클라이언트가 요청에 몇몇 제약을 넣기 위한 헤더이다. 조건부 요청 헤더를 사용하면 클라이언트는 서버에게 요청에 응답하기 전에 먼저 조건이 참인지 확인하게 하는 제약을 포함시킬 수 있다.
헤더 설명
헤더
설명
Expect
클라이언트가 요청에 필요한 서버의 행동 열거할 수 있게 해줌
If-Match
문서의 엔티티 태그가 주어진 엔티티 태그와 일치하는 경우에만 문서 가져옴
If-Modified-Since
주어진 날짜 이후에 리소스가 변경되지 않았다면 요청 제한
If-None-Match
문서의 엔티티 태그가 주어진 엔티티 태그와 일치하지 않는 경우에만 문서를 가져옴
If-Range
문서의 특정 범위에 대한 요청 가능
If-Unmodified-Since
주어진 날짜 이후에 리소스가 변경되었다면 요청 제한
Range
서버가 범위 요청을 지원하는 경우, 리소스에 대한 특정 범위를 요청
요청 보안 헤더 → 알아둬야 함!!!
트랜잭션을 더 안전하게 만들기 위해 클라이언트가 특정 리소스에 접근하기 전에 자신을 인증하게 할 수 있다.
헤더
설명
Authorization
클라이언트가 서버에게 제공하는 인증 그 자체에 대한 정보를 담고 있음
Cookie
클라이언트가 서버에게 토큰을 전달할 때 사용
Cookie2
요청자가 지원하는 쿠키의 버전을 알려줄 때 사용
프락시 요청 헤더
헤더
설명
Max-Forwards
요청이 원 서버로 향하는 과정에서 다른 프락시나 게이트웨이로 전달될 수 있는 최대 횟수
Proxy-Authorization
Authorization과 같으나, 프락시에서 인증을 할 때 사용
Proxy-Connection
Connection과 같으나 프락시에서 연결을 맺을 때 사용
응답 헤더
헤더
설명
Age
응답이 얼마나 오래되었는지 의미
Public
서버가 특정 리소스에 대해 지원하는 요청 메서드 목록
Retry-After
현재 리소스가 사용 불가능한 상태일 때, 언제 가능해지는지 날짜/시각
Server
서버 애플리케이션의 이름과 버전 → 알려줄 필요 없음
Title
HTML 문서에서의 제목
Warning
사유 구절에 있는 것보다 더 자세한 경고 메시지
협상 헤더
서버에 선택 가능한 여러가지 표현이 있을 경우, HTTP/1.1 은 서버와 클라이언트가 어떤 표현을 택할 것인가에 대한 협상을 할 수 있도록 지원한다.
헤더
설명
Accept-Ranges
서버가 자원에 대해 받아들일 수 있는 범위의 형태
Vary
응답에 영향을 줄 수 있는 헤더들의 목록(예시, 서버가 클라이언트에게 보내줄 리소스의 가장 적절한 버전을 선택하기 위해 살펴봐야 하는 헤더 목록)
응답 보안 헤더
헤더
설명
Proxy-Authentication
프락시에서 클라이언트로 보낸 인증요구의 목록
Set-Cookie
서버가 클라이언트를 인증할 수 있도록 클라이언트 측에 토큰을 설정하기 위해 사용 → Cookie 와 Set-Cookie의 관계 알아둬야 함
Set-Cookie2
Set-Cookie와 비슷하게 RFC 2965로 정의된 쿠키
WWW-Authenticate
서버에서 클라이언트로 보낸 인증요구의 목록
엔티티 헤더
요청과 응답 모두 엔티티를 포함할 수 있기에 엔티티 헤더는 양쪽에서 모두 나타날 수 있다.
엔티티 헤더가 제공하는 정보
엔티티 자체와 내용에 관한 정보
개체의 타입 ~ 주어진 리소스에 대해 요청할 수 있는 유효한 메서드
헤더
설명
Allow
해당 엔티티에 대해 수행될 수 있는 요청 메서드들
Location
클라이언트에게 엔티티가 실제로 어디에 위치하고 있는지 알려줌. 수신자에게 리소스에 대한 위치(새로운 url)을 알려줄 때 사용
콘텐츠 헤더
엔티티 콘텐츠에 대한 구체적인 정보를 제공한다. 콘텐츠의 종류, 크기, 기타 콘텐츠를 처리할 때 유용하게 활용될 수 있는 것들이다.
헤더
설명
Content-Base
본문에서 사용된 상대 url을 계산하기 위한 기저 url
Content-Encoding
본문에 적용된 인코딩
Content-Language
본문을 이해하는데 가장 적절한 자연어
Content-Length
본문의 길이/크기
Content-Location
리소스가 실제 위치하는 곳
Content-MD5
본문의 MD5 체크섬
Content-Range
전체 리소스에서 이 엔티티가 해당하는 범위를 바이트 단위로 표현
Content-Type
엔티티의 종류
엔티티 캐싱 헤더
엔티티 캐싱에 대한 정보를 제공한다. 리소스에 대해 캐시 사본이 아직 유효한지, 캐시된 리소스가 더 이상 유효하지 않게 되는 시점을 더 잘 추정하기 위한 단서 등을 제공한다.
Uniform Resource Locator의 약자. 인터넷 리소스를 가리키는 표준이름. 브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리킴
2-2. URL의 문법
동일한 문법으로 모든 사람이 동일한 규칙으로 리소스를 찾을 수 있음
<스킴>://<사용자이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>
주로 사용되는 URL 구조
<스킴>//<호스트>:<포트>/<경로>
예시
HTTP의 URL <http://www.joes-hardware.com/seasonal/index-fall.html>
- 그 외 프로토콜의 URL
FTP => , FTP 서버에 올라간 파일 가리킴
rtsp => rtsp://www.joes-hardware.com:554/interview/cto_video, 스트리밍을 제공하기 위해 비디오 서버에 호스팅하고 있는 영화를 가리킴
<a href="./hammer.html">
html 작성자는 url에 스킴, 호스트, 다른 컴포넌트를 입력하지 않아도 됨
기저 url을 통해 기술하지 않은 정보를 추측할 수 있기 때문.
여기서 기저 url은 <http://www.joes-hardware.com/tools.html>
