Jinhyuk Kim

[Real World HTTP] Chapter 1. HTTP/1.0의 신택스: 기본이 되는 네 가지 요소

• 기본이 되는 네 가지 요소
  • 메서드와 경로
  • 헤더
  • 바디
  • 스테이터스 코드

HTTP의 역사

• HTTP 버전 업 타임라인
  • 1990년: HTTP/0.9
  • 1996년: HTTP/1.0
  • 1997년: HTTP/1.1
  • 2005년: HTTP/2.0

HTTP/0.9로 할 수 있는 것을 시험하다

• 0.9 버전은 현행 프로토콜과 하위 호환성이 없으므로 완벽히 재현해보기 어렵다.
  • curl의 --http1.0 옵션으로 비슷하게 재현해본다.
• 0.9의 기본 기능은 웹사이트의 페이지를 요청하고, 응답으로 받아오는 것 뿐이다.
• <isindex> 태그를 사용해 검색을 하거나 URL에 ? 기호와 +로 구분된 단어를 넣으면 검색 요청을 할 수 있었다.

http://localhost:18888/?search+world

• 위 요청을 curl로 하면 다음과 같다.

$ curl --http1.0 --get --data-urlencode "search word" http://localhost:18888

• curl의 --data-urlencode는 쿼리 안의 공백이나 URL에 사용할 수 없는 문자가 없으면 치환해 쿼리로 만든다.

HTTP/0.9에서 1.0으로의 여정

• HTTP/1.0에서 요청의 변경된 점
  • 메서드가 추가됐다. (GET)
  • HTTP 버전이 추가됐다. (HTTP/1.0)
  • 헤더가 추가됐다. (Host, User-Agent, Accept)
• HTTP/1.0에서 응답의 변경된 점
  • HTTP 버전과 스테이터스 코드가 추가됐다.
  • 요청과 같은 형식의 헤더가 추가됐다.

HTTP의 조상 (1) 전자메일

HTTP의 헤더와 매우 유사한 형식의 헤더가 HTTP가 나오기 이전부터 전자메일에서 사용되었다.

헤더의 전송

• curl로 헤더를 보내려면 --header="이름: 값" (또는 -H "이름: 값") 옵션을 사용한다.

$ curl --http1.0 -H "X-Test: Hello" http://localhost:18888

• 같은 헤더를 여러 번 보내는 것도 가능하다.

헤더 수신

• curl 커멘드에 -v 옵션을 지정하면 응답 헤더를 볼 수 있다.

MIME 타입

• 전자메일을 위해 만들어진 파일의 종류를 구별하는 문자열 값
• 다양한 형식의 값이 사용되다가 RFC 1341에서 현재와 같은 형식으로 정립되었다. (text/html)
• RFC 1590에서 새로운 종류의 MIME 타입을 등록/신청하는 절차가 정해졌다.
• RFC 3023에서는 범용 포맷을 추가하는 방법을 정했다. (예. image/svg_xml)

Content-Type과 보안

• 인터넷 익스플로러는 MIME 타입이 아닌 내용을 보고 파일 형식을 추측하기도 한다.
• 이런 방식은 의도되지 않은 파일을 실행하게 만들 수 있어 보안상 문제가 있다.
• 다음과 같은 헤더를 전송하면 브라우저가 내용으로 파일 형식을 추측하지 않게 된다.

X-Content-Type-Option: nosniff

(참고: MDN X-Content-Type-Options 페이지)

HTTP의 조상 (2) 뉴스그룹

• 분산 아키텍쳐로 구성된 뉴스그룹의 포맷은 전자메일의 영향을 받아 책정되었다.
• HTTP는 뉴스그룹의 메서드와 스테이터스 코드의 영향을 받았다.

메서드

• 1.0부터 지금까지 자주 쓰이는 메서드: GET, POST, HEAD
• 1.0에서는 옵션이었으나 자주 쓰이는 메서드: PUT, DELETE

• 1.1에서 삭제된 메서드: LINK, UNLINK

• curl 커맨드로 메서드를 전송할 때는 --request= 혹은 -X 옵션을 사용한다.

$ curl --http1.0 -X POST http://localhost:18888

스테이터스

• 100번대: 처리가 계속됨을 나타낸다. 특수한 용도로 사용됨
• 200번대: 성공
• 300번대: 서버에서 클라이언트로의 명령
• 400번대: 클라이언트의 오류
• 500번대: 서버의 오류

리디렉트

• 메서드 변경이 가능한 스테이터스 코드가 있다.
  • 301 Moved Permanently / 302 Found
  • 첫 번째 요청이 POST일 때 리디렉트된 요청의 메서드를 GET이나 HEAD로 사용자 허가 없이 변경할 수 있다.
• 메서드 변경의 필요성 차이
  • 301 Moved Permanently / 308 Moved Permanently
    • 영구적 이동
  • 302 Found / 307 Temporary Redirect
    • 일시적 이동
    • 모바일 전용 사이트나 관리 페이지를 표시
  • 303 See Other
    • 반환할 콘텐츠가 없거나 원래 반환할 페이지가 따로 있을 때 이동
    • 예. 로그인 페이지에서 로그인 한 후 원래 페이지로 이동
• curl 커맨드에 -L 옵션을 사용하면 300번대 응답에 Location 헤더가 있을 때 헤더가 가진 URL로 다시 요청을 보낸다.
• 메서드를 바꾸지 못하게 하는 옵션(--post301, --post302, --post303)이 존재한다.
• 최대 리디렉트 횟수(-max-redirs)도 지정 가능하다.

$ curl -L http://localhost:18888

• HTTP/1.0 최초 RFC에는 리디렉스 횟수를 최대 5회로 제한했으나, RFC 2616의 HTTP/1.1에서는 제한이 없어졌다.
• 구글은 리디렉트 횟수를 최대 5회, 가능하면 3회 이하로 하기를 권장한다.

URL

• RFC 1738에서 정의했다. (상대 URL은 RFC 1808)
• HTTP/1.0보다 먼저 규격화되었다.
• URI에는 URN과 URL이 있으나, 웹에서는 URN을 사용할 일이 없으므로 URI와 URL을 서로 구분없이 사용하는 경우가 많다.

URL의 구조

스키마://사용자:패스워드@호스트명:포트/경로#프래그먼트?쿼리

• RFC 2718에서는 UTF-8로 URL을 인코딩하도록 정했다.
• HTTP 사양상 URL 길이에 제한은 없지만 IE는 2083자까지만 다루기 때문에 대부분 2000자를 제한으로 생각한다.
• HTTP/2에서 414 URI Too Long 스테이터스 코드가 추가되었다.

URL과 국제화

• RFC 3492에서 퓨니코드(Punycode)가 정해져 퓨니코드를 구현한 브라우저에서 URL의 도메인 이름으로 다국어를 사용할 수 있다.
  • 참고. 퓨니코드 변환 확인

바디

• HTTP/0.9에서는 요청에 데이터를 포함할 수 없었다.
• 헤더 끝에 빈 줄을 넣으면 그 이후는 모두 바디가 된다.
• 응답의 헤더에 바디의 바이트 수를 나타내는 Content-Length 헤더가 추가된다.

• 바디가 압축되어 있으면 Content-Encoding 헤더에 압축 알고리즘을 지정한다.

• curl 커맨드에서 바디를 서버에 보내려면 -d 옵션을 사용한다.
  • 기본 Content-Type은 application/x-www-form-urlencoded를 사용한다.
  • -d 옵션은 --data, --data-ascii의 줄임말이다. 문자를 변환하지 않는다.
  • --data-urlencode 옵션은 URL 사용 불가 문자를 변환한다.
  • --data-binary 옵션은 바이너리를 전송할 때 사용한다.
• 파일을 바디로 보내려면 파일명 앞에 @를 사용한다.

$ curl -d @test.json -H "Content-Type: application/json" http://localhost:18888

GET 요청 시의 바디

• RFC에 따르면 GET 요청 시에도 바디를 추가할 수 있지만 자주 사용하는 방식은 아니다.