1] HEAD

HEAD method는 GET과 동일하지만 서버는 응답에 content를 보내면 안된다.(must not)

HEAD는 representation data의 전송 없이 selected representation에 대한 메타데이터를 얻기 위해 사용된다. 흔히 hypertext links를 테스트하거나 최근 수정 사항을 찾기 위해 사용한다.

서버는 HEAD 요청을 보낼 때 응답으로 GET으로 요청을 보냈을 때와 동일한 header fields를 전송해야 한다.(should)

그러나 서버는 콘텐츠를 생성하는 동안에만 값이 결정되는 헤더 필드를 생략할 수 있다.(may)

예를 들어, 일부 서버는 GET에 대한 dynamic response를 최소한의 데이터가 생성될 때 까지 buffer한다.
더 효율적으로 small response의 범위를 정하거나 content 선택과 관련하여 늦은 결정을 내리기 위해서다.
이러한 것에는 Content-Length나 Vary 필드가 포함된다.
이것들은 HEAD 응답 내에서 생성되지 않는다.

이러한 사소한 불일치는 HEAD 요청에 대한 content를 생성하고 삭제하는 것보다 바람직하다. HEAD는 대개 효율성을 목적으로 요청되기 때문이다.

request message framing은 사용된 method와 무관하기 때문에 HEAD 요청에서 본문을 보낼 수 있지만, HEAD 요청에서의 본문은 의미가 없고, 본문을 보낸다고 해서 해당 요청의 의미나 대상을 변경할 수 없다.
또한 HTTP/1.1에서 request smuggling attack의 가능성 때문에 일부 구현에서 요청을 거부하고 연결을 닫을 수 있다.

client가 origin server와 직접 통신하고, 해당 요청에 목적이 있어 origin server가 HEAD 요청에 본문을 포함하는 것을 허용한다는 것을 코드상, 문서상 명시적으로 표시한 경우에만, client는 HEAD 요청에 본문을 포함할 수 있다.(should)

origin server는 content를 받을 때 private agreements에 의존해서는 안된다.(should not)
HTTP 통신의 참여자는 request chain을 따라 intermediaries를 알지 못하는 경우가 많기 때문이다.

HEAD 요청에 대한 응답은 캐시 가능하다.
캐시는 Cache-Control header field에서 지정하지 않는 한 후속 HEAD 요청을 충족하기 위해 사용할 수 있다.

HEAD 응답은 이전에 캐시된 GET 응답에도 영향을 미칠 수 있다.

---

Next Plan

Content-Length에 대한 설명 추가

Vary에 대한 설명 추가

request smuggling attack에 대한 설명 추가

Cache-Control에 대한 설명 추가

---

References

https://www.rfc-editor.org/rfc/rfc9110.html