📘 책을 읽으며 알게 된 지식을 정리하고 있습니다. 현재 읽고 있는 책은 야마모토 요헤이, <웹을 지탱하는 기술> (멘토르, 2011)입니다.
📍 저작권 상 문제가 있다면 글 삭제하도록 하겠습니다. 문제가 있으면 알려주세요.
📍 간략히 정리한 것이라 실제 책을 읽어보시면 많은 도움이 될 것이라 확신합니다. 자세히 알고 싶은 내용이셨다면 책을 살펴보시는 것을 추천합니다!
📌 오늘 다룰 것은 3부 HTTP(chapter 8 ~ 9, pp.171~230)에 해당하는 내용입니다.
1. 상태 코드
✔️ 응답 메시지 첫 줄 status line에서 가장 중요한 것
✨ RFC 2616에서 HTTP 1.1의 status code 확인하기
✔️ 상태 코드는 3자리 숫자
-
1nn: 처리 중
-
2nn: 성공
-
200 OK: 요청 성공
-
201 Created: 리소스 새로 작성 성공
-
-
3nn: 리다이렉트 (이 코드 받았다면, Location 헤더를 보고 새로운 리소스로 접속하게 해줄 것)
-
301 Moved Permanently: 해당 리소스는 Location 헤더로 전해준 URI로 "영구적으로" 이동되었음을 의미함 (일시적 변경은 302)
-
303 See Other: 리다이렉트 처리 결과를 취득(=GET)할 수 있는 다른 URI를 알려줌(Location 헤더에 담아). PUT/POST로 리소스를 조작하고, 그 결과를 GET으로 가져오도록 하기 위해 사용
내용을 수정하거나 추가하고 그 변경사항이 반영된 결과를 바로 볼 수 있는 것이 일반적이니까, 그런 결과를 볼 수 있게, Location 헤더에 담은 URI로 GET 요청을 보냄으로써 그 작업을 완성하라는 것인 듯?
-> 3nn을 받으면, 응답 메시지 Location 헤더에 담긴 URI로 클라이언트에서 추가로 요청을 보내야 하는 것인 듯?!
-
-
4nn: 클라이언트 에러 -> 잘못된 요청을 보냈을 때.
-
400 Bad Request: 요청 구문이나 파라미터가 잘못됐을 때 or 클라이언트 에러 나타내기 위한 적절한 상태 코드 없을 때
-
401 Unauthorized: 접근 권한 없음, 인증 실패. 적절한 인증 정보가 필요함.
-
404 Not Found: 해당 리소스를 찾을 수 없음. 바디에 이유를 담음.
-
-
5nn: 서버 에러, 서버에서 원인 해결하면, 동일한 요청 재전송했을 때 정상적인 결과 받을 가능성 有
-
500 Internal Server Error: 서버 내부 에러 발생으로 정상 응답 보낼 수 없을 때 or 서버 에러 나타내기 위한 적절한 상태 코드 없을 때
-
503 Service Unavailable: 서버 점검 등의 이유로 일시적으로 해당 서버에 엑세스 불가, Retry-After 헤더로 서비스 재개 시기가 대략 몇 초 후인지 알려줄 수 있음
-
⭐ 이처럼 상태 코드는 고정돼 있으므로, 임의로 추가할 수 없고, 이들을 올바르게 사용하는 것이 중요!
2. HTTP 헤더
✔️ Email 메시지 스펙(RFC 822)과 유사한 부분 多
📍 MIME 미디어 타입
-
MIME = Multipurpose Internet Mail Extensions, Email에서 차용한 스펙임을 이름에서 알 수 있음
복수의 메일 헤더를 정의하는 스펙임
HTTP에서는 그중 몇 개만을 이용
-
MIME 미디어 타입 = '미디어 타입'
Content-Type
-
메시지의 바디 내용이 어떤 type(종류)인지를 미디어 타입으로 나타냄
ex. Content-Type: application/xhtml+xml; charset=utf-8
✔️ application = 타입 (text, image 등 9개의 타입이 있음)
✔️ xhtml+xml = 서브타입 (XHTML 문서를 의미함)
✔️ charset 파라미터 = 문자 인코딩 방식 지정
Content-Language
-
리소스 표현의 자연 언어를 지정
ex. Content-Language: ko-KR
✔️ ko = ISO 639가 정의하는 언어 코드 (ko, en)
✔️ KR = ISO 3166이 정의하는 지역 코드 (KR, US)
📍 Content-Type(미디어 타입 & 인코딩 방식), Content-Language 이용해 서버가 일방적으로 결정할 수도 있고, 클라이언트와 콘텐트 네고시에이션을 통해 정할 수도 있음
Accept
-
클라이언트에서 처리할 수 있는 미디어 타입을 서버에게 전달할 때 이용
ex.
Accept: text/html, application/xhtml+xml, application/xml; q=0.9, */*;q=0.8✔️ 우선도: qvalue(= q 파라미터의 값)로 나타냄, 0~1의 값 갖고, 클수록 우선도 높음
-
text/html, application/xhtml+xml = 1 (기본값)
-
application/xml = 0.9
-
나머지 모든 미디어 타입 = 0.8
-
✔️ Accept 헤더에 지정한 미디어 타입에 서버가 대응하지 않고 있다면 406 Not Acceptable 반환
Accept-Charset
-
클라이언트에서 처리할 수 있는 문자 인코딩을 서버에 전달할 때 이용
ex.
Accept-Charset: EUC-KR;utf-8;q=0.7, */*;q=0.7✔️ EUC-KR이 최우선, Accept-Charset 헤더의 기본 문자 인코딩인 ISO 8859-1이 그 다음 우선(우선도는 둘 다 1), UTF-8 및 그밖의 방식이 0.7의 우선도
Accept-Language
-
클라이언트에서 처리할 수 있는 언어를 서버에 전달할 때 이용
ex.
Accept-Language: ko, en-us;q=0.7, en;q=0.3✔️ 한국어가 1, 미국 영어가 0.7, 지역 특정하지 않는 영어가 0.3의 우선도
WWW-Authenticate
- 응답 메시지에서, 401 Unauthorized와 함께, 리소스 접근에 어떤 인증 정보가 필요한지 알려줄 때 사용
캐시 관련 헤더
캐시
-
서버로부터 가져온 리소스를 로컬 스토리지에 저장해 재사용하는 방법 또는 로컬 스토리지에 캐싱한 데이터 자체
-
클라이언트: 서버에서 가져온 리소스의 캐시 가능 여부 조사, 가능하면 로컬 스토리지에 저장함
Pragma
Pragma: no-cache
-> 값을 캐시하지 마시오!
Expires
-
캐시의 유효기간을 나타냄
-
클라이언트: 유효기간 확인하고, 캐시를 이용할지 서버에 다시 접속할지를 결정
-
리소스 변경 가능성이 없는 리소스더라도 1년 이내의 기간을 설정할 것
Cache-Control
✔️ Pragma, Expires의 기능 + a -> 복잡한 지정을 위해 HTTP 1.1에서 추가한 헤더
Cache-Control: no-chace, Cache-Control: max-age: 86400
-
Expires의 값으로는 절대 시간만 사용 가능, Cache-Control은 상대 시간도 사용 가능
max-age: 86400 = 지금으로부터 86400초(=24시간)동안 유효하다
Connection
- HTTP 1.1에서부터, 서버와 클라이언트의 지속적 접속이 기본 동작이 됨
-> 클라이언트가 요청하고 서버가 응답하면 바로 TCP 커넥션을 끊던 기존 방식에서 변화한 것
✔️ Pipelining(파이프라인화): 클라이언트가 응답을 기다리지 않고, 같은 서버에 요청을 보낼 수 있음 = 효율적 메시지 처리 가능
✔️ Connection 헤더에 close 값을 지정하면 커넥션을 끊을 수 있음
ex.
GET /test HTTP/1.1
Host: example.com
Connection: close
-> 이 요청의 응답이 반환된 후 접속을 끊는다!라는 의도를 전달
📍 이것들 외에도 다양한 헤더가 존재합니다!
