헤더와 바디
<리얼월드 HTTP> 도서의 내용을 요약 정리하고 관련 내용을 추가하였습니다.
HTTP
HTTP는 웹 브라우저와 웹 서버가 통신하는 절차와 형식을 규정한 것이다. 더 나아가 번역 api나, 데이터 저장 api등 다양한 서비스의 인터페이스로 사용되면서 인터넷의 기초가 됐다.
다양한 프로토콜이 RFC로 정의됐다. RFC는 통신의 상호접속성 유지를 위한 공통화된 사양서 모음을 의미한다.
HTTP 헤더
헤더는 파일명:값 형식으로 본문 앞에 부가된다. 헤더 이름은 대, 소문자를 구별하지 않는다. http에도 이 전자메일과 같은 똑같은 형식의 헤더가 도입됐다.
1. 클라이언트가 서버에 보내는 헤더
• User-Agent : 클라이언트가 자신의 애플리케이션 정보를 나타내는 곳. 스마트폰, pc의 브라우저 종류나 버전을 구분할 수 있다.
• Referer : 서버에서 참고하는 추가 정보. 클라이언트가 요청을 보낼 때 보고 있던 페이지의 url을 보낸다. 페이지의 참조원을 서버가 참조하하는데 이용한다.
• Authorization: 특별한 클라이언트에만 통신을 허가할 때, 인증 정보를 서버에 전달한다. aws나 git api등에서는 웹 서비스 자체 표기를 요구하기도 한다(?)
2. 서버에서 클라이언트로 보낼 때 부여하는 헤더
• Contet-Type : 파일 종류를 지정. mime 타입이라는 식별자를 기술한다.
• Content-Length : 바디 크기. 만약 압축이 이루어지는 경우 압축 후의 크기가 들어간다.
• Content-Encoding : 압축이 이루어진 경우, 압축 형식을 설명한다.
• Date : 문서 날짜
• 또한 이 밖에 X-로 시작되는 헤더는 각 애플리케이션이 자유롭게 사용해도 된다.
헤더의 전송
curl 커맨드로 실제 헤더를 보낼 수 있다. 헤더는 —header=헤더행 or -H옵션을 사용한다.
1 | curl —http1.0 -H “X-test: hello” http//localhost:8000 |
MIME 타입
파일의 종류를 구분하는 문자열.
인터넷 옵션에 따라 mime타입이 아닌 내용을 보고 파일 형식을 추측하려 하는데 이런 동작을 콘텐츠 스니핑이라고 한다. 그런데 만약 text파일에 html, js가 써있으면 파일을 실행해버리는 문제가 생길 수도 있다. 이런 문제를 해결하기 위해서 다음과 같이 옵션을 추가한다.
1 | X-content-type-option: nosniff |
메서드
http/1.0으로 통신할 때 전송되는 get부분은 메서드로 불린다. 다음 3가지가 흔히 쓰이는 메서드이다.
• get : 서버에 헤더와 콘텐츠 요청
• head: 서버에 헤더만 요청
• post : 새로운 문서 투고
html의 폼에서는 get과 post만 지원된다.
스테이터스 코드
3자리 숫자를 보고 서버가 어떻게 응답했는지 파악한다.
• 100번대 : 처리가 계속됨을 나타낸다.
• 200번대 : 성공했을 때의 응답.
• 300번대 : 서버에서 클라이언트로의 명령. 정상 처리의 범주이며 리디렉트나 캐시 이용을 지시한다.
• 400번대 : 클라이언트가 보낸 요청에 오류가 있다.
• 500번대 : 서버 내부에서 오류가 발생했다.
리디렉트
서버는 브라우저에 대해 리디렉트하도록 지시할 수 있다. 300이외의 경우는 location헤더를 사용해 리디렉트할 곳을 서버에서 클라이언트로 전달한다. 리디렉트에는 다섯 가지 종류가 있다.
• 301 moved permanently : 도메인 전송, 웹사이트 이전, https
• 302 found : 일시적 관리, 모바일 기반 전송
• 303 see other : 로그인 후 페이지 전환
• 307 temporary redirect: ..
영구적인지 일시적인지는 이동하는 이전 페이지가 이후에도 존재하는지로 분류한다. http → https 로의 전환은 http를 볼 일이 없으므로 영구적이다.
클라이언트는 Location헤더 값을 보고 다시 요청한다.
Url
Uri에는 urn이라는 이름 부여 규칙도 포함된다. url은 장소로 문서 등의 리소스를 특정하는 수단을 제공한다. 다시 말해, url은 주소이며, urn은 이름 그 자체이다. urn 예시는 다음과 같다.
웹 시스템을 다루는 한 urn이 등장할 일은 없으므로 uri와 url은 거의 같다.
url의 구조
스키마://호스트명/경로
• 스키마 : https
• 호스트명: www.oreilly.co.jp
• 경로: index.html
Url 사양에 포함되는 모든 요소가 들어간다면, 다음과 같은 형식이 된다.
1 | 스키마://사용자:패스워드@호스트명:포트/경로#프래그먼트?쿼리 |
사용자 이름과 패스워드는 FTP등에서 사용되곤 하는데, 여기서 기술하는 방식은 basic인증으로, 패스워드가 그대로 노출되어 웹 시스템에서 사용되는 일은 없다.
프래그먼트는 html에서는 페이지 내 링크의 앵커를 지정하는 데 쓰인다.
쿼리는 검색 용어를 지정하거나 표시하고 싶은 웹페이지에 대해서 특정 파라미터를 부여하는 데 쓰인다.
처음에는 url의 도메인 이름을 영숫자와 하이픈만 쓸 수 있었지만, 국제화 도메인 네임을 표현하는 인코딩 규칙 퓨니코드가 정해져 다국어를 사용할 수 있게 되었다.
바디
헤더 마지막 줄에 빈 줄을 넣으면 그 이후는 모두 바디가 된다. 한 번 응답할 때마다 한 파일만 반환한다. 폼이나 xmlhttprequest를 사용해 클라이언트에서 서버로 데이터를 전송하는 경우도 있다.