4장

HTTP 헤더와 콘텐츠 — 무엇을·어떤 형식으로

헤더는 왕복 서신의 곁들임 메모. 받는 곳의 Host, 형식과 문자 인코딩의 Content-Type, 양의 Content-Length, 희망을 전하는 Accept 계열, 그리고 스테이트리스 위에 세션을 만드는 Cookie 와 Set-Cookie 를 읽는다.

본문은 맞는데, 왠지 깨진다·다른 것이 돌아온다

HTML 은 올바르게 썼을 텐데 문자가 「譁�蟄�」처럼 깨진다. API 에 JSON 을 보냈는데 「형식이 잘못되었다」고 거부당한다. 같은 URL 인데 사람에 따라 다른 언어의 페이지가 나온다 — 이런 「본문은 맞는데」 계열의 트러블의 답은, 대개 본문이 아니라 헤더에 있습니다.

헤더는 왕복 서신에 곁들여지는 이름: 값 형식의 곁들임 메모입니다. 편지에 비유하면, 받는 이·「파손 주의」 라벨·무게 표기·회신용 이름표 — 본문 그 자체는 아니지만, 본문을 어떻게 다뤄야 하는지를 정하는 정보가 여기에 모여 있습니다. 3 점 세트의 세 번째 「조건과 보충」입니다.

헤더는 수백 종류가 있지만, 암기는 불필요합니다. 이 장에서는 「어디로 보내는가·무엇이 얼마나·어떤 희망으로·누구로부터인가」에 답하는 대표 6 가지만 읽습니다.

HTTP 의 왕복 서신에 받는 곳의 Host, 형식의 Content-Type, 양의 Content-Length, 희망의 Accept, 이름표의 Cookie 라는 곁들임 메모가 붙어 있는 모습을 나타낸 그림

헤더는 본문에 곁들여진 라벨입니다. 받는 곳(Host)·내용물의 표시(Content-Type / Content-Length)·희망(Accept 계열)·이름표(Cookie / Set-Cookie) — 역할로 묶으면, 수백 종류의 헤더도 무섭지 않게 됩니다.

Host — 1 개의 주소에, 여러 개의 문패

리퀘스트의 필수 헤더 Host: example.com 은 편지의 받는 이입니다. 「IP 주소에 접속해 있으니 받는 곳은 자명하지 않은가?」라고 생각할지 모르지만, 실제로는 1 대의 서버(1 개의 IP 주소)에서 www.example.com 과 shop.example.com 처럼 여러 사이트를 함께 두는 운용이 보통입니다.

TCP 접속은 건물의 현관까지만 안내해 줍니다. 어느 방(사이트) 앞인지는 편지의 받는 이 — Host 헤더 — 로 전합니다. 서버는 이것을 보고 돌려줄 내용을 전환합니다. 이것이 이름 기반 가상 호스트이고, Host 가 빠진 리퀘스트가 HTTP/1.1 에서 오류가 되는 것은, 받는 이 없는 편지는 배달할 수 없기 때문입니다.

Content-Type 과 Content-Length — 내용물은 무엇이고, 얼마나 되는가

리스폰스의 Content-Type: text/html; charset=UTF-8 은 「내용물은 HTML 이고, 문자 인코딩은 UTF-8 입니다」라는 라벨입니다. 앞부분의 text/html(MIME 타입)로 브라우저는 「그려야 할 HTML 인가, 표시할 이미지인가, 다운로드시킬 파일인가」를 정하고, 뒷부분의 charset 으로 바이트열을 어느 문자 인코딩으로 문자로 되돌릴지를 정합니다.

여기가 글자 깨짐의 입구입니다. 실체는 UTF-8 로 저장되어 있는데 charset=Shift_JIS 라고 선언하면, 브라우저는 고지식하게 잘못된 규칙으로 바이트열을 읽어 문자가 깨집니다. 오류가 되지 않고 깨진 채로 표시되는 것이 성가신 점으로, 대처는 「라벨과 내용물을 일치시킨다」 이 한 가지입니다. 참고로 Content-Type 은 리스폰스 전용이 아닙니다 — POST 로 JSON 을 보낼 때는, 리퀘스트 쪽에 Content-Type: application/json 을 붙여 내용물의 형식을 전합니다.

Content-Length: 1256 은 「바디는 1256 바이트입니다」라는 양의 표기입니다. 1 개의 TCP 접속을 돌려쓰며 몇 통이든 편지를 주고받는 HTTP/1.1 에서는, 수신 쪽은 어디까지가 이번 바디인지를 알아야 하고, 이 숫자가 그 구분이 됩니다.

Accept 계열 — 희망을 전하고, 골라 받는다

같은 URL 이라도, 원하는 형태는 상대에 따라 다릅니다. 브라우저는 HTML 을 원하고, 프로그램은 JSON 을 원합니다. 일본어 화자에게는 일본어 페이지를 돌려주고 싶다. 이 「희망」을 전하는 것이 Accept 계열의 리퀘스트 헤더입니다.

Accept: application/json

「가능하면 JSON 으로 주세요」— 형식의 희망

Accept-Language: ja

「가능하면 일본어로 주세요」— 언어의 희망

Accept-Encoding: gzip

「압축해서 보내 주셔도 됩니다」— 전송 방법의 희망

서버는 제공할 수 있는 표현 중에서 골라 돌려줍니다. 이것이 콘텐츠 니고시에이션(내용의 교섭)입니다. 요점은 강제가 아니라 교섭이라는 것 — 희망이 통하지 않을 수도 있고, 실제로 무엇이 돌아왔는지는 리스폰스 쪽의 Content-Type 등으로 확인합니다. 「같은 URL 인데 사람에 따라 겉모습이 다르다」의 속사정 중 하나가 여기에 있습니다.

Cookie 와 Set-Cookie — 스테이트리스 위에 세션을 만든다

제 1 장의 숙제를 회수합니다. HTTP 는 스테이트리스라서, 서버는 「아까의 계속」을 기억하지 않는다. 그렇다면 로그인 상태는 어떻게 실현하고 있는가 — 답은 2 개의 헤더의 연계입니다.

Step 1 — 서버가 이름표를 발행한다

로그인 성공의 리스폰스에 Set-Cookie: session=abc123 을 곁들인다. 「이후에는 이 이름표를 보여 주세요」

Step 2 — 브라우저가 이름표를 보관한다

브라우저는 Cookie 를 그 사이트용으로 기억한다

Step 3 — 이후의 리퀘스트에 매번 곁들인다

같은 사이트로의 리퀘스트에는 자동으로 Cookie: session=abc123 이 붙는다. 서버는 이름표를 보고 「아까 그 사람이다」라고 안다

즉 세션이란, 스테이트리스한 왕복 서신의 1 통 1 통에, 같은 이름표를 계속 곁들임으로써 만들어지는 「이어지는 이야기」입니다. 서버가 기억하고 있는 것은 「이름표 abc123 은 누구인가」라는 대응표뿐이고, HTTP 자체는 끝까지 스테이트리스인 채 — 이 구도를 읽을 수 있으면, 「Cookie 를 지웠더니 로그아웃되었다」「다른 브라우저에서는 로그인하지 않은 취급이 된다」 같은 일상의 현상이 전부 설명됩니다.

이 장에서 가져갈 것

헤더는 왕복 서신의 곁들임 메모. 본문을 어떻게 다룰지를 정하는 정보가 모인다
Host 는 받는 이 — 1 개의 IP 에 여러 사이트가 함께 사는 이름 기반 가상 호스트를 지탱하는 필수 헤더
Content-Type(+ charset)은 라벨. 라벨과 내용물의 불일치가 글자 깨짐의 입구. Content-Length 는 바디의 바이트 수로, 메시지의 구분을 알려 준다
Accept 계열은 희망의 표명(교섭이지 강제가 아니다). Set-Cookie → Cookie 의 이름표 왕복이, 스테이트리스 위에 세션을 만든다

다음 장은 헤더의 응용편이자, Web 의 빠르기의 심장부 — 캐시입니다. 「같은 것을 두 번 나르지 않기」 위한 조건과 보충을, 손 계산과 시뮬레이터로 확인합니다.