백엔드 공부 메모/네트워크

HTTP 헤더(3) - 리퀘스트 헤더 필드

볼륨조절불가 2024. 3. 1. 15:39
728x90

 

 

* 해당 게시글은 <그림으로 배우는 Http&Network Basic>을 읽고 정리하면서 공부하기 위해 메모하듯 작성하는 글입니다.

 

 

 

 

Accept

Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
  • 유저 에이전트에서 처리할 수 있는 미디어 타입과 미디어 타입의 상대적인 우선 순위를 서버로 전달하기 위해 사용
    • ‘미디어 타입/서브 타입’의 형태로도 설정 가능
    • 여러 개 설정 가능
  • 서버가 복수의 컨텐츠를 반환할 수 있는 경우→반환할 수 있는 가장 높은 우선 순위의 미디어 타입 반환

종류

텍스트 파일

  • text/html, text/plain, text/css, ...
  • application/xhtml+xml, application/xml, ...

이미지 파일

  • image/jpeg, image/gif, image/png

동영상 파일

  • video/mpeg, video/quicktime, ...

애플리케이션용 바이너리 파일

  • application/octet-stream, application/zip, ...

우선순위 지정 방법

[미디어 타입];q=[우선순위 값(0에서 1 사이, 소수점 세자리까지 조정 가능)]
  • 1로 갈수록 우선순위가 높아짐
  • 우선순위 생략하는 경우 암묵적으로 q=1.0으로 처리

 

 

 

 

Accept-Charset

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
  • 유저 에이전트에서 처리할 수 있는 문자셋과, 그 우선 순위를 서버에 알려주는 역할
  • Accept 헤더 필드와 비슷하게 우선 순위 지정 가능

 

 

 

 

Accept-Encoding

  • 유저 에이전트가 처리할 수 있는 콘텐츠 코딩과 그 우선 순위를 서버로 전달하기 위해 사용
  • Accept 헤더 필드와 비슷하게 우선 순위 지정 가능
  • *(애스터리스크) 이용시 모든 인코딩 포맷 지정 가능→와일드 카드 역할

가능한 콘텐츠 코딩 종류

  • gzip
    • 파일 압축 프로그램 gzip(GNU zip)에서 생성된 인코딩 포맷
  • compress
    • UNIX 파일 압축 프로그램 “compress”에 의해 만들어진 인코딩 포맷
  • deflate
    • Zlib 포맷과 deflate 압축 알고리즘에 의해 만들어진 인코딩 포맷을 조합한 것
  • identity
    • 압축, 변형하지 않는 디폴트 인코딩 포맷

 

 

 

 

Accept-Language

  • 유저 에이전트가 처리할 수 있는 자연어의 세트와 그 우선 순위를 서버로 전달하기 위해 사용
  • Accept 헤더 필드와 비슷하게 우선 순위 지정 가능
Accept-Language: ko-kr, en-us;q=0.7, en;q=0.3
  • 위의 헤더 사용 예시의 의미: 한국어 리소스가 있으면 한국어로(우선순위 1등), 없으면 영어로(2, 3등) 받고 싶다는 뜻

 

 

 

 

Authorization

Authorization: Basic asklfjKLifKSLDJFLSKJFid==
  • 유저 에이전트의 인증 정보(크리덴셜 값)를 전달하기 위해 사용
  • 서버로부터 401 Unauthorized 리스폰스를 받은 뒤에 해당 헤더 파일을 포함한 리퀘스트 전달
  • 공유 캐시가 Authorization 헤더 필드를 포함하는 리퀘스트를 받으면 조금 다른 동작 진행→7장 참고

 

 

 

 

Expect

Expect: 100-continue
  • 클라이언트가 서버에 특정 동작을 요구
  • 기대하는 요구에 서버가 응답하지 못해 에러 발생→상태 코드 417 Expectation Failed 반환
  • HTTP/1.1에서는 100-continue만 정의됨
    • 상태 코드 100 Continue 의미

 

 

 

 

From

From: abcdefg1234@gmail.com
  • 유저 에이전트를 사용하고 있는 유저의 메일 주소를 서버로 전달
  • 주로 검색 엔진 등의 에이전트 책임자에게 연락처 메일 주소를 나타내는 목적으로 사용
  • 에이전트를 사용하느 경우 되도록이면 From 헤더 필드 포함해야 함(또는 User-Agent 헤더 필드)

 

 

 

 

Host

Host: www.hackr.jp
  • 리퀘스트한 리소스의 인터넷 호스트와 포트 번호를 서버에 전달
  • HTTP/1.1에서 유일한 필수 헤더 필드
    • 필수인 이유는 가상 호스트의 구조와 매우 깊은 관련이 있음
  • 서버에 호스트명이 설정되어 있지 않은 경우→헤더 필드 값을 비워서 리퀘스트 요청
If-xxx 라는 서식의 리퀘스트 헤더 필드를 조건부 리퀘스트라고 부름
→서버는 지정된 조건에 맞는 경우에만 리퀘스트 수용
 
 
 
 

If-Match

If-Match: "123456"
  • 서버 상의 리소스를 특정하기 위해 엔티티 태그(ETag) 값을 전달
    • 이때 서버는 약한 ETag 값 사용할 수 없음→뭔소리일까
  • If-Match의 필드 값과 리소스의 ETag 값이 일치한 경우에만 리퀘스트 수용 가능
  • ETag 불일치→412 Precondition Failed 리스폰스 반환
  • 필드 값에 와일드카드(*) 사용 가능→리소스가 존재하기만 하면 리퀘스트 처리 가능

엔티티 태그

  • 특정 리소스와 관련된 값
  • 리소스가 갱신되면 ETag도 갱신

 

 

 

 

If-Modified-Since

If-Modified-Since: Thu, 15 Apr 2004 00:00:00 GMT
  • 요청하는 리소스가 해당 필드 값으로 지정된 날짜 이후에 갱신된 리소스인지 서버 측에서 확인
    • 갱신되었다면 갱신 일자를 Last-Modified 헤더 필드에 추가한 뒤, 상태 코드 200 OK와 함께 리소스 반환
    • 갱신되지 않았다면(not modified) 상태 코드 304 Not Modified 리스폰스 반환

 

 

 

 

If-None-Match

  • If-Match와 정반대로 동작
    • ETag 값이 일치하지 않으면(즉, 갱신되었으면) 서버 측에서 리퀘스트를 수용해 서버 내 리소스 전달
  • If-Modified-Since 헤더 필드를 사용하는 것과 비슷

 

 

 

 

If-Range

GET /index.html
If-Range: "123456"
Range: bytes=5001-10000
  • 헤더 필드 값으로 전달되는 ETag 값(혹은 날짜)이 동일하면(즉, 갱신이 안 됐으면!) 서버 측에서 Range 리퀘스트로 처리
    • 불일치시 전체 범위를 리소스로 반환

사용 이유

  • 클라이언트 측에서 리소스의 일부를 소유하고 있어 서버에 요청하기 전, 서버 측 리소스의 변경이 생긴다면 레인지 리퀘스트 요청에 의미가 없어지므로(무효) 서버는 상태 코드 412 Precondition Failed 리스폰스를 반환
  • 그래서 클라이언트는 리소스를 재요청해야 함
  • 이때 If-Range 헤더 필드를 사용하면 1회의 요청만으로 위의 상황을 처리 가능

 

 

 

 

If-Unmodified-Since

  • If-Modified-Since 헤더 필드와 정반대로 동작
  • 지정된 날짜 이후에 갱신되지 않은 경우에 리퀘스트 처리
    • 갱신된 경우에는 상태 코드 412 Precondition Failed 반환

 

 

 

 

Max-Forwards

  • TRACE 혹은 OPTIONS 메소드에 의한 리퀘스트 과정에서, 전송해도 좋은 서버 수의 최대치를 10진수 정수로 지정
  • 서버가 다음 서버에 리퀘스트 전송시 Max-Forwards 값에서 1을 빼서 전송
  • Max-Forwards 값이 0인 리퀘스트를 받은 경우 , 다음 서버로 리퀘스트 전송하지 않고 리스폰스 반환

사용 이유

  • HTTP 통신에서 리퀘스트가 프록시 서버 등 여러 대의 서버를 경유해 가는 경우 존재
  • 도중에 프록시 서버에서 리퀘스트 전송 실패시 클라이언트는 리스폰스를 못 받아 실패 사실을 알 수 없음
  • 이때 응답이 어디에서 끊기는지 조사하기 위해 Max-Forwards 헤더 필드가 활용

 

 

 

 

Proxy-Authorization

  • 프록시 서버에서 인증 요구를 받아들인 때에 인증에 필요한 클라이언트의 정보 전달
  • Authorization 헤더 필드와 같은 역할
    • 클라이언트와 프록시 사이의 인증 과정에 사용된다는 것이 차이점

 

 

 

 

Range

Range: bytes=5001-10000
  • 레인지 리퀘스트를 할 때 사용
  • 요구하고 싶은 리소스의 범위를 지정
  • 레인지 리퀘스트 정상 처리: 상태 코드 206 Partial Content 반환
    • 처리할 수 없는 경우: 완전한 리스폰스(200 OK) 반환

 

 

 

 

Referer

Referer: http://www.hackr.jp/index.htm
  • 리퀘스트가 발생한 본래 리소스의 URI 전달
  • 기본적으로 Referer 헤더 필드는 보내져야 함
    • 브라우저 주소창에 직접 URI를 입력한 경우, 보안상 바람직하지 않은 경우 보내지 않음

 

 

 

 

TE

TE: trailers, deflate;q=0.5
  • 리스폰스로 받을 수 있는 전송 코딩의 형식과 상대적인 우선 순위 전달
  • TE 헤더를 사용한 리퀘스트를 받은 서버는 청크 전송 코딩으로 리스폰스 전달→따로 지정 안해주고 이 헤더만 쓰면 됨
  • Accept-Encoding 헤더 필드(콘텐츠 코딩)와 매우 비슷하나, 여기서는 전송 코딩에 적용

지정 형식

  • gzip
  • deflate
  • compress
  • trailer
    • Trailer를 동반하는 청크 전송 인코딩 형식

 

 

 

 

User-Agent

User-Agent: Mozilla/1.0 (Windows NT 6.1) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.195
  • 리퀘스트를 생성한 브라우저와 유저 에이전트의 이름 등을 전달하기 위해 사용
  • 참고: 프록시 경유한 리퀘스트의 경우, 프록시 서버의 이름 등이 부가된 것도 존재
728x90