배경 어떤 구성원의 프로필 사진을 조회할 수 있는 API가 있다. 해당 API는 구성원의 프로필 사진 URL을 구해서, 302 응답을 내려준다. (Location 헤더에 프로필 사진 URL) 해당 API는 Authorization 헤더를 참조해 인증/인가 작업을 거친다. 프로필 사진 URL에 접근할 때도 Authorization 헤더가 필요하다. 프로필 사진 조회 API와 프로필 사진 URL의 호스트는 다르다. API를 호출해보니 리다이렉트는 되었지만 프로필 사진 URL 조회 시에 인증 실패가 발생한다. 원인 Postman이나 curl 명령어 등 대부분의 HTTP 클라이언트에서는 다른 호스트로 리다이렉트 될 때 Authorization 헤더는 유지하지 않고 요청을 보낸다....
301 Moved Permanently: 리퀘스트된 리소스에는 새로운 URI로 영구히 이동되었기 떄문에 이후로는 그 리소를 참조하는 URI를 사용해야된다는 뜻이다. 새로운 URI는 Location 헤더 필드에 명시되어 있다. 브라우저는 이 페이지로 리디렉션되고 리소스에 대한 링크를 업데이트 한다. 302 Found: 리퀘스트된 리소스가 새로운 URI로 일시적으로 이동했다는 뜻이다. 브라우저는 사용자를 이 URL의 페이지로 리다이렉트시키지만 리소스에 대한 링크가 업데이트 되지 않는다. 참고 자료 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301 https://developer.mozilla.org/ko/docs/Web/HTTP/Status/302
이를 이해하기 위해서는 멱등성이라는 개념을 알아야된다. 멱등성은 동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니는지를 나타내는 성질이다. 대표적으로 GET, PUT, DELETE가 멱등성을 가지고, POST, PATCH는 멱등성을 가지지 않는다. PUT의 경우에는 요청의 body 내용을 그대로 리소스를 교체하게 되지만, PATCH는 사이드 이펙트가 있는 업데이트다. https://junroot.github.io/programming/REST/#http-메서드를-사용하여-요청의-의미를-가지게-하기
탄생 배경 HTTP/1.1 클라이언트가 웹 서버와 정보 교환을 하기위해 만드러진 프로토콜이다. 클라이언트가 서버에게 GET이나 POST 같은 메소드와 함께 요청을 보내면, 서버는 HTML이나 이미지 같은 리소스를 다시 클라이언트에게 보낸다. 이렇게 하나의 요청과 응답을 주고 받는 과정에는 한 개의 애플리케이션 레이어 프로토콜이 사용된다고 생각하면 된다. HTTP/1.1은 아래와 같이 텍스트 기반 형식으로 메시지를 보낸다. GET /index.html HTTP/1.1 Host: www.example.com HTTP/2 Google에서 개발한 SPDY라는 프로토콜을 기반으로 시작되었다. HTTP/2는 압축, 멀티플렉싱, 우선 순위 지정과 같은 기술을 사용해 웹 페이지의 로딩 시간을 줄였다....
목표 SameSite 쿠키가 무엇인지 이해한다. SameSite 쿠키의 정책들을 이해한다. SameSite 쿠키 HTTP 쿠키에 사용할 수 있는 속성으로 cross-site로 요청을 보낼 때 해당 쿠키를 보낼 수 있을지 설정할 수 있다. CSRF 공격에 대한 대응으로 사용할 수 있는 속성이다. SameSite 속성의 쿠키를 설정하려면 아래와 같이 명시하면 된다. Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict SameSite 정책 Strict: 크로스 사이트 요청에 항상 전송하지 않는다. 퍼스트 파티 쿠키만 전송된다. Lax: 이미지나 iframe 에서는 크로스 사이트에 전송하지 않지만, 해당 사이트로 이동할 때 쿠키가 전송된다....
이번에는 현재 IETF의 인터넷 초안 상태인 HTTP/3에 대해서 알아본다. HTTP/3는 기존의 HTTP 버전들과 다르게 TCP를 사용하지 않는다. Transport layer에서 TCP가 아닌 QUIC을 사용한다. QUIC은 Quick UDP Internet Connection의 약자로 구글에서 개발한 UDP기반의 프로토콜이다. 이 QUIC에서 제공하는 기능에는 어떤 것이 있을까. 보안 기존에 TCP + HTTP/2를 사용할 때는 보안을 위해 별도의 TLS 레이어가 필요했다. QUIC은 자체적으로 보안 기능을 내장하고 있어 별도의 TLS 레이어를 둘 필요가 없어졌다. 이렇게 결합하면 어떤 이점이 있을까? 기존의 TCP + TLS의 경우에는 클라이언트와 서버가 연결을 시작할 때 TCP의 3-Way Handshake와 TLS 자체의 Handshake가 따로 필요했었다....
서버가 찻주전자이기 때문에 커피 내리기를 거절했다는 것을 의미한다. 이 오류는 1998년 만우절 농담이었던 하이퍼 텍스트 커피 포트 제어 규약(Hyper Text Coffee Pot Control Protocol)의 레퍼런스다.