3징 HTTP 메시지

메시지의 흐름

HTTP 메시지는 HTTP 애플리케이션 간에 주고받은 데이터의 블록들이다.
데이터 블록들은 메시지의 내용과 의미를 설명하는 텍스트 메타 정보로 시작하고 그 다음에 선택적으로 데이터가 올 수 있다.
메시지는 클라이언트, 서버, 프락시 간에 교환된다.
인바운드, 아웃바운드, 업스트림, 다운스트림은 메시지의 방향을 의미한다.

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

HTTP는 인바운드와 아웃바운드라는 용어를 트랜잭션 방향을 표현하는데 사용한다.

  • 메시지가 서버로 향하는 것을 인바운드라고 한다.
  • 모든 처리가 끝난 뒤에 메시지가 클라이언트로 향하는 것을 아웃바운드라고 한다.

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

  • 메시지가 클라이언트에서 서버로 흐르는 것을 다운스트림으로 흐른다고 한다.
  • 메시지가 서버에서 클라이언트로 흐르는 것도 다운스트림으로 흐른다고 한다.
  • 메시지의 발송자는 수신자의 업스트림이다.

메시지의 각 부분

HTTP 메시지는 단순한, 줄 단위의 문자열이다.
메시지는 시작줄, 헤더 블록, 본문으로 구성된다.

메시지 부분 설명 예시
시작줄 어떤 메시지인지 서술한다. HTTP/1.0 200OK
헤더 속성 Content-type : text/plain
Content-length: 19
본문 데이터 Hi! I’m a message!

시작과 헤더는 줄바꿈 문자(CRLF)로 구분되며, 아스키 문자열이다.
본문은 단순 데이터 덩어리이며, 임의의 이진 데이터를 포함할 수 있다.

메시지 문법

모든 HTTP 메시지는 요청 메시지나 응답 메시지로 분류된다.

  • 요청 메시지 형식
<메서드> <요청 URL> <버전>
<헤더>
<본문>
  • 응답 메시지 형식
<버전> <상태 코드> <사유 구절>
<헤더>
<본문>

메서드

클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작이다.
ex) GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT

요청 URL

요청하고자 하는 리소스를 가리킨다. 완전한 URL 혹은 URL의 경로 부분만 포함할 수 있다.

버전

HTTP 버전을 가리킨다.

상태 코드

요청 중 무엇이 일어났는지 설명하는 세 자리 숫자이다.

사유 구절

숫자로 된 상태 코드를 설명해주는 짧은 문구이다.

헤더

헤더는 이름과 값으로 구성된 속성의 목록이다.

본문

엔티티 본문은 요청이나 응답에 포함된 데이터이다.

시작줄

요청 메시지의 시작줄은 무엇을 해야 하는지 말해준다.
응답 메시지의 시작줄은 무슨 일이 일어났는지 말해준다.

요청줄

요청줄은 메서드, 요청URL, HTTP버전을 포함한다.
모든 필드는 공백으로 구분된다.

ex) GET /home.html HTTP/1.1

응답줄

응답줄은 HTTP버전, 상태 코드, 사유 구절을 포함한다.
모든 필드는 공백으로 구분된다.

ex) HTTP/1.1 200 OK

메서드

메서드는 서버가 수행해주길 바라는 동작이다.
HTTP 명세는 공통 요청 메서드의 집합을 정의한다.

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

모든 서버가 위 표의 메서드를 구현한 것은 아니다.
HTTP는 확장 가능한 프로토콜이기 때문에 새로운 메서드를 정의할 수 있다.

상태 코드

상태 코드는 클라이언트에게 무엇이 일어났는지 말해준다.
상태 코드는 세 자리 숫자로, 200 ~ 299는 성공, 300 ~ 399는 리소스가 옮겨졌음, 400 ~ 499는 클라이언트 에러, 500 ~ 599는 서버 에러를 의미한다.

전체 범위 정의된 범위 분류
100-199 100-101 정보
200-299 200-206 성공
300-399 300-305 리다이렉션
400-499 400-415 클라이언트 에러
500-599 500-505 서버 에러

사유 구절

사유 구절은 상태 코드를 설명해주는 짧은 문구이다.

버전 번호

버전 번호는 HTTP/x.y 형식을 따른다.
x는 메이저 버전, y는 마이너 버전을 의미한다.
HTTP/1.1은 메이저 버전 1, 마이너 버전 1을 의미한다.
버전 번호는 분수로 다루어지지 않는다. 따라서 HTTP/2.22는 HTTP/2.3보다 크다.

헤더

헤더는 이름과 값으로 구성된 속성의 목록이다.

헤더 분류

  • 일반 헤더 : 요청과 응답 양쪽에 모두 나타낼 수 있음
  • 요청 헤더 : 요청에 대한 부가 정보를 제공
  • 응답 헤더 : 응답에 대한 부가 정보를 제공
  • 엔티티 헤더 : 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 서술
  • 확장 헤더 : 명세에 정의되지 않은 새로운 헤더

엔터티 본문

HTTP 메시지는 선택적으로 엔터티 본문을 포함할 수 있다.
엔터티 본문은 요청이나 응답에 포함된 데이터이다.
HTTP 메시지는 이미지, 비디오, HTML 문서, JSON 객체 등 모든 종류의 데이터를 포함할 수 있다.

버전 0.9 메시지

HTTP 버전 0.9는 HTTP 프로토콜의 초기 버전이다.

메서드

HTTP 메서드에 대해 자세히 알아보자.

안전한 메서드(Safe Methods)

HTTP 메서드는 안전한 메서드와 안전하지 않은 메서드로 나뉜다.
안전한 메서드는 서버의 상태를 변경하지 않는다.
안전한 메서드는 GET, HEAD 메서드이다.

GET

GET은 주로 서버에서 리소스를 달라고 요청하기 위해 쓰인다.

HEAD는 GET과 비슷하지만 서버는 응답으로 헤더만 보낸다.

HEAD를 사용하면

  • 리소스를 가져오지 않고도 그에 대해 무엇인가를 알아낼 수 있다.
  • 리소스가 존재하는지 확인할 수 있다. (응답 상태코드를 통해)
  • 리소스가 변경되었는지 확인할 수 있다. (응답 헤더의 Last-Modified 필드를 통해)

서버 개발자들은 반드시 반환되는 헤더가 GET과 HEAD에서 동일하도록 해야한다.

PUT

PUT은 서버에 문서를 쓴다.
PUT메서드의 의미는, 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체하는 것이다.
PUT은 서버에 새 문서를 만들거나, 기존 문서를 교체할 때 사용한다.

POST

POST는 서버에 입력 데이터를 전송할 때 사용한다.

TRACE

클라이언트가 어떤 요청을 할 때, 그 요청이 서버에 도달하기까지 어떤 경로를 거쳐서 갔는지 알려준다.(방화벽, 프록시, 게이트웨이 등의 애플리케이션)
TRACE 메서드는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다.

TRACE 요청은 서버에 도달하면 서버는 자신이 받은 요청을 그대로 반환한다.
TRACE 메서드는 주로 진단을 위해 사용한다.
예를 들어 클라이언트가 서버에 도달하기까지 어떤 프록시를 거쳐갔는지 알고 싶을 때 사용한다.

OPTIONS

OPTIONS 메서드는 서버가 어떤 메서드를 지원하는지 알려준다.

DELETE

DELETE 메서드는 서버에서 리소스를 제거할 때 사용한다.

확장 메서드

HTTP는 확장 가능한 프로토콜이다.

확장 메서드의 대표적인 예

  • LOCK : 리소스를 잠근다.
  • MKCOL : 새 컬렉션을 만든다.
  • COPY : 리소스를 복사한다.
  • MOVE : 리소스를 옮긴다.

상태 코드

HTTP 상태 코드는 크게 다섯 가지로 나뉜다.

1xx : 정보성 상태 코드

상태 코드 사유 구절 설명
100 Continue 서버가 요청의 일부를 받았으며 나머지를 계속 받을 것을 알려준다.
101 Switching Protocols 클라이언트가 Upgrade 헤더에 나열한 것 중 하나로 서버가 프로토콜을 바꾸었음을 의미한다.

100 Continue는 HTTP 클라이언트 애플리케이션이 서버에 엔터티 본문을 전송하기 전에 그 엔터티 본문을 서버가 수용할 수 있는지 확인하기 위해 사용한다.
이는 프로그래머를 혼란스럽게 하는 경향이 있어 자세히 살펴보자.

  • 클라이언트와 100 Continue
    • 클라이언트가 서버에 엔터티 본문을 보내려고 하고, 그 전에 100 Continue 응답을 기다리겠다면, 클라이언트는 값을 100-continue로 하는 Expect 요청 헤더를 보낼 필요가 있다.
    • 만약 클라이언트가 엔터티를 보내지 않으려고 한다면 Expect 요청 헤더를 보내지 않아야 한다. 왜냐하면 서버는 클라이언트가 보낼 것이라고 생각하게 만들어 서버를 혼란에 빠뜨리기 때문이다.
    • 100 Continue는 최적화를 위한 것이다.
    • 보통은 큰 엔터티 본문을 서버가 다루거나 할 수 없는 경우 서버에 보내지 않으려는 목적으로 사용해야 한다.
    • 클라이언트가 100 Continue 응답을 막연히 기다리지만 해서는 안되고 약간의 타임아웃 후에 클라이언트는 엔터티 본문을 보내야 한다.
  • 서버와 100 Continue
    • 서버가 100-continue 값이 담긴 Expect 헤더가 포함된 요청을 받는다면, 100-Continue 응답 혹은 에러 코드로 답해야 한다.
    • 서버가 응답을 보낼 기회를 갖기전에 엔터티를 수신했다면 서버는 100 상태 코드를 보낼 필요가 없다. 그러나 서버가 요청을 끝까지 다 읽은 후에는 최종 응답을 보내야한다. 이 경우 100 상태 코드는 생략 가능하다.
    • 만약 서버가 100 continue 응답을 받을 것을 의도한 요청을 받고 난 상태에서 엔터티 본문을 읽기전에 요청을 끝내기로 결정했다면, 응답을 보내고 연결을 닫아서는 안된다.
  • 프록시와 100 Continue
    • 프록시는 클라이언트로 부터 100 응답을 의도한 요청을 받았으면 HTTP/1.1 이상의 버전인 경우 또는 어떤 버전을 따르는지 모르는 경우 Expect 헤더를 포함시켜서 요청을 다음 홉으로 전달해야한다.
    • 만약 다음 홉이 HTTP/1.1 보다 아래의 버전을 따른다면 프록시는 417 Expectation Failed 응답을 보내야 한다.

2xx : 성공 상태 코드

클라이언트가 요청을 보내면 그 요청을 대개 성공한다.
서버는 대응하는 성공을 의미하는 상태 코드를 가지고 있다.

상태 코드 사유 구절 설명
200 OK 요청은 정상이고, 엔터티 본문은 요청한 리소스를 포함한다.
201 Created 서버에 개체를 생성하라는 요청에 대한 응답으로, 응답은 생성된 리소스에 대한 참조 정보를 포함한다. 참조 정보는 Location 헤더와 함께
202 Accepted 요청은 접수되었지만, 서버가 요청을 처리하지 못했다. 서버는 요청을 처리할 수 있는 상태가 되면 요청을 처리할 것이다. 서버는 가급적이면 요청의 처리가 언제 완료 될 것인지 추정해서 알려주면 좋다.
203 Non-Authoritative Information 서버가 요청을 성공적으로 처리했지만, 응답이 로컬 또는 전역적으로 캐시된 사본일 수 있다.
204 No Content 서버가 요청을 성공적으로 처리했지만, 응답으로 보낼 엔터티 본문이 없다. 클라이언트는 엔터티 본문을 업데이트하지 않아도 된다. 주로 폼을 갱신하고자 할때 사용한다.
205 Reset Content 주로 브라우저를 위해 사용되는 상태 코드로 브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우라고 말한다.
206 Partial Content 서버가 Range 헤더에 지정된 범위의 부분적 요청을 성공적으로 처리했다.

3xx : 리다이렉션 상태 코드

리다이렉션 상태 코드는 클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 그 리소스의 내용 대신 다른 응답을 제공한다.
리다이렉션 상태 코드는 리소스에 대한 로컬 복사본이 최신인지 원래 서버에 있는 리소스가 수정되었는지 검사할 수도 있다.

상태 코드 사유 구절 설명
300 Multiple Choices 서버가 요청에 대해 여러 리소스를 가리키고 있다. 클라이언트는 이 중 하나를 선택해야 한다.
301 Moved Permanently 요청한 리소스가 Location 헤더에 주어진 URL에 옮겨졌다. 클라이언트는 이후의 모든 요청을 새로운 URL로 보내야 한다.
302 Found 301 상태 코드와 같다. 302는 클라이언트가 요청한 리소스가 일시적으로 다른 위치에 있지만, 앞으로도 다른 위치에 있을 것이라는 것을 의미한다.
303 See Other 서버가 요청에 대한 리소스를 다른 URL에 두고 있다. 새 URL은 Location 헤더에 있다. 주로 POST 요청에 대한 응답으로 클라이언트에게 리소스의 위치를 알려주는 것이다.
304 Not Modified 클라이언트가 리소스를 마지막으로 가져온 이후로 리소스가 수정되지 않았다. 클라이언트는 로컬에 있는 사본을 사용할 수 있다.
305 Use Proxy 요청한 리소스는 Location 헤더에 주어진 URL에 있는 프록시를 사용해서 접근해야 한다. 클라이언트는 모든 요청을 프록시로 보내야 한다.
307 Temporary Redirect 302와 같다. 307은 클라이언트가 요청한 리소스가 일시적으로 다른 위치에 있지만, 앞으로도 다른 위치에 있을 것이라는 것을 의미한다.

4xx : 클라이언트 에러 상태 코드

클라이언트가 서버가 다룰 수 없는 무언가를 보내면 서버는 4xx 상태 코드를 반환한다.

상태 코드 사유 구절 설명
400 Bad Request 서버가 요청의 구문을 인식하지 못했다.
401 Unauthorized 클라이언트가 요청한 리소스에 접근하기 위해서는 인증이 필요하다. 클라이언트는 요청을 인증해야 한다.
402 Payment Required 예약되어 있음
403 Forbidden 서버가 요청을 거부하고 있다. 서버는 요청을 이해했지만, 승인을 거부했다. 클라이언트는 요청을 보내지 말아야 한다.
404 Not Found 서버가 요청한 리소스를 찾을 수 없다.
405 Method Not Allowed 서버가 요청된 메서드를 지원하지 않는다.
406 Not Acceptable 서버가 요청의 Accept 헤더 필드에 명시된 특성을 만족하는 응답을 생성할 수 없다. 클라이언트는 Accept 헤더 필드를 수정해야 한다.
407 Proxy Authentication 프록시가 요청을 처리하기 위해서는 클라이언트가 먼저 자신을 인증해야 한다. 클라이언트는 프록시 서버에게 자신을 인증하기 위한 Proxy-Authorization 헤더를 보내야 한다.
408 Request Timeout 클라이언트가 서버의 응답을 기다리는 동안에 시간이 너무 오래 걸렸다. 클라이언트는 요청을 다시 보내야 한다.
409 Conflict 서버가 요청을 처리하는 동안 충돌이 발생했다. 클라이언트는 요청을 다시 보내야 한다.
410 Gone 서버가 요청한 리소스를 영구적으로 더 이상 제공하지 않는다. 클라이언트는 이후에 이 리소스에 대한 요청을 보내지 말아야 한다.
411 Length Required 서버가 Content-Length 헤더 필드를 요구했지만, 클라이언트가 이 필드를 포함시키지 않았다. 클라이언트는 이 필드를 포함시켜야 한다.
412 Precondition Failed 서버가 요청의 전제 조건을 만족하지 않았다. 클라이언트는 요청의 전제 조건을 충족시켜야 한다.
413 Request Entity Too Long 서버가 요청의 본문이 너무 길다.
414 Request-URI Too Long 서버가 요청의 URI가 너무 길다.
415 Unsupported Media Type 서버가 요청의 엔터티 본문을 이해할 수 없다. 클라이언트는 요청의 엔터티 본문을 서버가 이해할 수 있는 형식으로 변환해서 보내야 한다.
416 Requested Range Not 서버가 요청의 Range 헤더 필드에 명시된 범위에 해당하는 리소스를 가지고 있지 않다. 클라이언트는 다른 범위를 요청해야 한다.
417 Expectation Failed 서버가 Expect 요청 헤더에 명시된 확장을 지원하지 않는다. 클라이언트는 요청을 다시 보내지 말아야 한다.

5xx : 서버 에러 상태 코드

서버가 요청을 처리하는 동안에 서버 자체에서 에러가 발생하면 서버는 5xx 상태 코드를 반환한다.

상태 코드 사유 구절 설명
500 Internal Server Error 서버가 요청을 처리할 수 없게 만드는 에러를 만났을 때 사용한다.
501 Not Implemented 서버가 요청을 처리할 수 없다. 클라이언트가 요청한 메서드를 지원하지 않는다.
502 Bad Gateway 서버가 게이트웨이나 프록시 역할을 하고 있고, 요청을 처리하는 동안에 잘못된 응답을 받았다.
503 Service Unavailable 서버가 요청을 처리할 준비가 되지 않았다.
504 Gateway Timeout 서버가 게이트웨이나 프록시 역할을 하고 있고, 요청을 처리하는 동안에 응답이 너무 오래 지연되었다.
505 HTTP Version Not Supported 서버가 요청에 사용된 HTTP 프로토콜 버전을 지원하지 않는다.

헤더

HTTP 헤더는 이름과 값으로 구성된 속성의 목록이다.
헤더는 요청과 응답 양쪽에 모두 나타날 수 있다.
헤더는 일반 헤더, 요청 헤더, 응답 헤더, 엔티티 헤더, 확장 헤더로 나뉜다.

일반 헤더

  • 메시지에 대한 아주 기본적인 정보를 제공한다.
  • Date 헤더 처럼 요청과 응답 모두 같은 의미를 가진다.
헤더 이름 설명
Connection 클라이언트와 서버 간의 연결을 유지할지 닫을지를 말해준다.
Date 메시지가 만들어진 날짜와 시간을 말해준다.
MIME-Version 메시지가 따르는 MIME 버전을 말해준다.
Trailer chunked transfer 메시지에 있는 특정 헤더들을 본문 뒤에 나열한다.
Transfer-Encoding 어떤 인코딩이 본문에 적용되었는지 말해준다.
Upgrade 클라이언트가 업그레이드를 원한다면 서버에게 말해준다.
Via 메시지가 어떤 프록시를 거쳐서 왔는지 말해준다.
  • 일반 캐시 헤더
헤더 이름 설명
Cache-Control 메시지와 함께 캐시 지시자를 전달하기 위해 사용한다.
Pragma 메시지와 함께 지시자를 전달하는 또 다른 방법, 캐시에 국한되지 않는다.

요청 헤더

  • 요청 헤더는 요청 메시지에서만 의미를 갖는 헤더이다.
헤더 이름 설명
Client-IP 클라이언트의 IP 주소를 말해준다.
From 사용자의 이메일 주소를 말해준다.
Host 요청한 호스트의 이름을 말해준다.
Referer 요청한 리소스의 이전 리소스를 말해준다.
User-Agent 요청을 보내는 클라이언트의 애플리케이션 정보를 말해준다.
  • 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 프록시가 서버에게 제공하는 인증 그 자체를 말해준다.
Proxy-Connection 프록시가 클라이언트와 서버 간의 연결을 유지할지 닫을지를 말해준다.

응답 헤더

  • 응답 헤더는 클라이언트에게 부가 정보를 제공한다.
헤더 이름 설명
Age 응답이 얼마나 오래되었는지 말해준다.
Public 서버가 지원하는 메서드를 말해준다.
Retry-After 서버가 다시 요청을 받을 수 있는 시간을 말해준다.
Server 서버가 사용하는 소프트웨어의 이름과 버전을 말해준다.
Title HTML 문서의 제목을 말해준다.
Warning 응답에 대한 추가 정보를 말해준다.
  • 협상 헤더
헤더 이름 설명
Vary 서버가 확인해 보아야 하고 그렇기 때문에 응답에 영향을 줄 수 있는 헤더들의 목록
Accept-Ranges 서버가 리소스의 특정 범위의 형태를 지원하는지 말해준다.
  • 응답 보안 헤더
헤더 이름 설명
Set-Cookie 서버가 클라이언트에게 제공하는 쿠키를 말해준다.
Set-Cookie2 서버가 클라이언트에게 제공하는 쿠키의 버전을 말해준다.
WWW-Authenticate 서버가 클라이언트에게 보낸 인증요구의 목록
Proxy-Authenticate 프록시에서 클라이언트에게 보낸 인증요구의 목록

엔티티 헤더

헤더 이름 설명
Allow 리소스에 대해 허용되는 메서드를 말해준다.
Location 클라이언트에게 엔터티가 실제로 어디에 위치하고 있는지 말해준다.
  • 콘텐츠 헤더
헤더 이름 설명
Content-Encoding 엔터티 본문에 적용된 인코딩을 말해준다.
Content-Language 엔터티 본문에 적용된 자연 언어를 말해준다.
Content-Length 엔터티 본문의 길이를 말해준다.
Content-Location 엔터티 본문이 실제로 어디에 위치하고 있는지 말해준다.
Content-MD5 엔터티 본문의 MD5 체크섬을 말해준다.
Content-Range 엔터티 본문의 특정 범위에 대한 정보를 말해준다. 바이트 단위로
Content-Type 엔터티 본문의 MIME 타입을 말해준다.
Content-Base 엔터티 본문에 있는 모든 상대 URL의 기준 URL을 말해준다.
  • 엔티티 캐시 헤더
헤더 이름 설명
ETag 엔터티 태그를 말해준다.
Expires 엔터티가 만료되는 날짜와 시간을 말해준다.
Last-Modified 엔터티가 마지막으로 수정된 날짜와 시간을 말해준다.

문제

  1. 인바운드와 아웃바운드, 다운스트림와 업스트림을 설명하시오.
  2. 요청 메시지와 응답 메시지의 형식을 설명하시오.
  3. HTTP 버전번호에 대해 설명하시오. ex) HTTP/1.1
  4. 예를 들어 당신이 github의 서버 개발자라고 할 때 private repository에 대한 요청을 거부할 때 어떤 상태코드로 응답할지와 이유를 설명하시오.
  5. 정보성 상태코드 100 Continue에 대해 설명하시오.

results matching ""

    No results matching ""