HTTP Method가 뭔데요 (3)

메서드 정의 뭔지 알아보기.. 근데 일단 GET이랑 HEAD랑 POST만...

시작..

지난 포스팅에선 공통 메서드 속성을 정리해봤습니다.. 이제 메서드 정의에 대해서 정리해보려고 합니다.

GET

GET 메서드는 클라이언트가 서버에서 데이터를 요청할 때 사용되는 메서드로 서버는 요청된 리소스의 현재 상태나 표현을 반환합니다.

그렇다면 GET 메서드가 가지는 특징은 무엇이 있을까요!

데이터 요청

맞습니다.. GET은 데이터 요청 그 자체 아닐까요?

클라이언트가 서버에 GET 요청을 보내면, 서버는 해당하는 리소스의 현재 상태를 가져와 클라이언트에게 반환합니다. 예를 들어, 우리가 어느 웹 사이트에 접속한다고 가정해봅시다. 그럼 우리 웹 브라우저가 웹 페이지를 요청하고 서버는 HTML 문서를 반환할 것입니다.

캐싱

우리 안전한 메서드인 GET 요청의 응답은 캐시될 수 있습니다. 그렇다면 동일한 응답에 대해 서버에 요청하지 않고 캐시된 데이터를 사용하여 서버 부하도 줄이고 네트워크 트래픽도 감소시킬 수 있습니다.

사실 저번 포스팅의 메서드와 캐싱 부분에서 다룬 내용들이니 짧게 설명하고 넘어가겠습니다.

Cache-Control 헤더를 통해 응답의 캐싱 동작을 제어할 수 있습니다. ‘no-store’, ‘no-cache’ 이런 거 말이죠!
‘Etag’, ‘Last-Modified’ 헤더로 캐시된 리소스의 유효성도 검사할 수 있습니다.

안전성과 멱등성

사실 이 내용도 이미 이전 포스팅들에서 다룬 내용들입니다.

GET 요청은 서버의 상태를 변경하지 않고, 동일한 요청을 여러 번 반복해도 항상 동일한 응답이 반환됩니다.

때문에 GET 메서드는 안전한 메서드이며 멱등성을 가집니다.

범위 요청

만약 클라이언트가 큰 용량을 가진 파일의 일부만 필요하다면, Range 헤더를 사용해 해당하는 부분만 요청할 수 있습니다… 이것도 이전 포스팅에서 다룬 조건부 요청입니다.

‘Range: bytes=0-999’ 이렇게 요청하면 파일의 처음 1000 바이트만 요청합니다. 이러한 범위 요청에 대한 응답 코드는 ‘206 Partial Content’ 형식으로 받습니다.

데이터 전송 방식

어라 만약 GET 요청을 하는데 우리가 데이터를 전송한다면 어떻게 전송할까요?? 예를 들자면, 특정 키워드에 대한 검색 같은 거요!

쿼리 문자열을 사용합니다.

GET 요청에서 데이터를 전송할 때, URL에 쿼리 문자열을 포함하여 데이터를 전달하게 됩니다. 쿼리 문자열은 보통 ‘?’ 뒤에 키-값의 형태로 표현합니다.

각 키-값은 ‘=’ 기호로 구분되며, 만약 여러 쌍이 존재한다면 ‘&’ 기호로 연결합니다!

예를 들어, https://www.gojimin.com/search?query=rtx4090&sort=rating 에서 ‘query=rtx4090’과 ‘sort=rating’ 이렇게 두 개를 쿼리 문자열로 볼 수 있습니다!

쿼리 문자열은 주로 서버에서 받아오는 데이터에 필터링을 걸거나, 검색 조건 (예를 들자면 추천순이 있겠죠?) 등의 정보를 전달할 때 사용됩니다.

그런데.. 이렇게 쿼리 문자열로 데이터를 전송한다면 과연 안전할까요??

안전하지 않습니다.

URL은 브라우저의 주소창에 표시되고, 브라우저 기록에 남고, 로그 파일, 리퍼러 헤더 등에 저장될 수 있어 보안에 취약합니다. 만약에 우리가 로그인하는데 비밀번호를 쿼리 문자열로 사용한다고 생각해봅시다.

https://www.gojimin.com/login?id=jimin&password=secret 이렇게 로그인한다면 우리의 민감한 정보가 노출될 수 있으니 이런 경우엔 POST를 사용해야 됩니다.

요약하자면

GET 요청은 클라이언트가 서버에 특정 리소스를 요청할 때 사용되는 메서드로 서버는 요청된 리소스를 찾아 응답 본문(body)에 포함시켜 클라이언트에게 전달합니다.

쿼리 문자열을 통해 데이터를 전송하는데 URL에 포함되어 키-값의 형태로 데이터를 전송합니다.

하지만 민감한 정보를 포함하는 것은 보안에 취약하기 때문에 이러한 경우엔 POST를 사용해야만 합니다.

HEAD

HEAD는 어떤 특징을 가질까요? GET이랑 비슷한 거 아닌가요???

응답 본문이 없습니다..

HEAD 요청은 GET 요청과 동일한 방식으로 처리되지만, 중요한 차이점으로 서버가 응답 본문(body)을 전송하지 않습니다.

HEAD 요청에 대한 서버의 응답엔 상태 라인과 헤더만 있을뿐 데이터(본문)는 포함하지 않습니다.

어떻게 동작하나요??

클라이언트:
- 클라이언트는 서버에 특정 리소스에 대한 HEAD 요청을 보냅니다. 이 요청은 GET이랑 비슷한 형태를 가집니다. 하지만 클라이언트는 이 요청을 보낼 때 body를 받을 생각으로 보내진 않을 겁니다.
- 예를 들자면 ‘HEAD /jimin.html HTTP/1.1’ 요청을 서버로 보낸다면 우린 ‘/jimin.html’에 해당하는 리소스의 메타데이터를 기대하고 요청하는 것이죠!
서버:
- 이제 서버는 HEAD 요청을 수신하면, 해당하는 리소스의 메타데이터를 포함한 헤더를 생성해 응답하게 됩니다. 이제 이 과정에서 서버는 body를 생성하지 않으므로 보내는 데이터의 양이 줄어들게 됩니다. 즉, 빠르게 응답이 가능한 것입니다.
- 예를 들어, 서버는 ‘Content-Length’, ‘Content-Type’, ‘Last-Modified’ 등의 헤더를 포함해 응답하게 됩니다.

언제 사용될까요?

리소스 크기 확인: 클라이언트가 특정 파일의 크기를 확인하고 싶을 때 HEAD 요청을 사용할 수 있습니다! 우리가 파일 크기를 알고 싶다고 GET 요청으로 파일 전체를 다운로드 받는 대신 HEAD 요청으로 확인하면 효율적이지 않을까요?
```
HEAD /bigbigbigfile.zip HTTP/1.1
Host: www.gojimin.com
```
```
HTTP/1.1 200 OK
Content-Type: application/zip
Content-Length: 10240000
```
이 응답으로 우리는 ‘bigbigbigfile.zip’ 파일의 크기가 10240000 바이트임을 알 수 있게 됩니다.
수정 날짜 확인: 우리가 리소스의 마지막 수정 날짜를 확인할 때도 HEAD 요청을 사용할 수 있습니다.
```
HEAD /certificate.pdf HTTP/1.1
Host: www.gojimin.com
```
```
HTTP/1.1 200 OK
Content-Type: application/pdf
Last-Modified: Mon, 13 Feb 2022 09:11:00 KST
```
이 응답으로 우리는 ‘certificate.pdf’ 파일의 수정 날짜가 2022년 2월 13일 월요일 오전 9시 11분임을 알 수 있게 됩니다!
링크의 유효성 검사: 웹 크롤러나 봇이 하이퍼링크의 유효성을 테스트할 때도 HEAD 요청을 사용합니다. 이를 통해 링크가 유효한지 확인해 불필요한 데이터 전송을 피합니다.
```
HEAD /index.html HTTP/1.1
Host: www.gojimin.com
```
```
HTTP/1.1 200 OK
Content-Type: text/html
```
이렇게 ‘index.html’에 접근이 가능한지도 확인이 가능합니다.

헤더 필드

서버는 HEAD 요청에 대해 GET 요청과 동일한 헤더 필드를 포함합니다. 이는 클라이언트가 리소스의 메타데이터를 확인하기 위함이죠??

그런데 여기서 생략이 가능한 헤더 필드가 존재합니다.

바로 동적으로 생성되는 값에 대한 헤더 필드는 생략될 수 있습니다. 당연할 수도 있는데 HEAD 요청은 body를 받지 않습니다. 그렇다면 동적인 데이터를 생성할 필요도 없지 않을까요??

예를 들어, 특정한 컨텐츠를 버퍼링하면서 ‘Content-Length’와 ‘Vary’ 필드를 결정한다고 생각해봅시다. 그런데 HEAD 요청에선 이 컨텐츠를 만들지도 않으니까 이런 헤더 필드를 생략할 수 있는 것입니다.

생략이 가능한 필드가 있지만.. 서버는 가능하다면 GET 요청과 동일한 헤더 필드를 반환해야 됩니다. 이는 헤더의 일관성을 유지해 클라이언트가 HEAD 요청으로 해당 리소스의 상태를 정확하게 파악할 수 있도록 합니다. (’Content-Type’, ‘Last-Modified’가 있겠죠?)

보안적인 고려 사항?

Although request message framing is independent of the method used, content received in a HEAD request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]).

저는 이 부분이 참 뭐라는걸까.. 싶었습니다. 하나씩 뜯어봐야겠습니다.

1. 요청 메세지 프레이밍은 사용된 메서드와 독립적이다.

쉽게 우리가 어떤 메서드를 사용하던 HTTP 요청 메세지의 구조는 항상 동일한 구조를 가집니다.
예를 들어, GET을 쓰던, POST를 쓰던, HEAD를 쓰던 항상 요청 메세지의 기본 구조인 요청 라인, 헤더, 본문으로 이루어진다는 말입니다. 하지만 일부 메서드에서는 사용되지 않습니다.

GET /posts/411 HTTP/1.1
Host: www.gojimin.com

요청 라인: ‘GET /posts/411 HTTP/1.1’
헤더: ‘Host: www.gojimin.com’
본문: 없음

HEAD /index.html HTTP/1.1
Host: www.gojimin.com

요청 라인: ‘HEAD /index.html’
헤더: ‘Host: www.gojimin.com’
본문: 없음

POST /submit HTTP/1.1
Host: www.gojimin.com
Content-Type: application/json
Content-Length: 18

{
	"name": "jimin",
}

요청 라인: ‘POST /submit HTTP/1.1
헤더: ‘HOST: www.gojimin.com’, ‘Content-Type: application/json’, ‘Content-Length: 18’
본문: ‘{ “name”: “jimin” }

이렇게 어떤 메서드를 사용하더라도 기본적인 구조는 동일하며 본문의 경우 일부 메서드에선 사용되지 않는 것을 알 수 있습니다.

2. HEAD 요청에서 보내는 내용은 일반적으로 정의된 의미가 없고, 이 요청의 의미나 대상은 변경될 수 없다.

HEAD 요청은 본문을 포함하지 않으므로, 본문이 없는 요청입니다.
‘일반적으로 정의된 의미가 없다’ 즉, HEAD 요청에 본문을 포함하더라도 이는 특별한 의미를 가지지 않습니다. HEAD 요청이 원래 본문을 가지지 않으니까요.
‘요청의 의미나 대상은 변경될 수 없다’ 이 말은 HEAD 요청에 본문이 포함되더라도 요청의 원래 의미나 목적이 변경되지 않는다는 것을 의미합니다. 원래 HEAD가 리소스의 메타데이터를 가져오는 것이 목적인데, 본문을 포함한다고 이 목적이 바뀌지 않는다는 것입니다.

3. 요청에 본문을 포함하는 것은 스머글링 공격의 우려로 요청 거부 및 연결이 종료될 수 있다.

HEAD 요청에 본문을 포함하면 일부 서버에서는 이를 스머글링 공격으로 간주할 수 있다고 합니다.
스머글링 공격은 HTTP 서버 구현 간에 헤더 해석간 불일치를 이용한 취약점 공격이라고 하는데 HRS 공격을 방지하는 구문 분석 기능도 존재한다고 합니다.
때문에 서버는 HEAD 요청에 본문이 포함될 경우 이를 비정상적인 요청으로 간주하고 요청을 거부하거나 연결을 종료할 수 있다고 합니다.

요약하자면

HEAD 요청은 GET 요청과 동일하게 처리됩니다. 하지만 응답 본문을 포함하지 않습니다.

본문을 포함하지 않는 이유는:

HEAD 요청은 리소스의 메타데이터를 빠르게 확인하기 위해 사용됩니다. 서버는 본문을 전송하지 않음으로써 네트워크 대역폭을 줄일 수 있습니다.
HEAD 요청의 목적은 본문 없이 헤더 정보만을 얻는 것으로 본문을 포함하는 것은 의미가 없습니다.
HEAD 요청에 본문을 포함하는 것은 잠재적인 위협으로 간주되며, 서버는 이를 비정상적인 요청으로 간주해 요청 거부 및 연결을 종료할 수 있습니다.

HEAD 요청은 리소스 크기, 수정 날짜 확인 그리고 유효성 검사 등에 사용됩니다.

POST

POST 메서드는 요청 본문에 포함된 데이터를 처리하도록 서버에 요청하는 메서드입니다. 우리가 보내는 본문 데이터는 다양한 용도로 사용될 수 있습니다.

어떻게 사용될까요??

The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.

문서에선 POST 메서드는 요청에 포함된 데이터를 대상 리소스가 고유한 방식(특정 시맨틱스)에 따라 처리하도록 요청한다고 합니다..

쉽게 좀 풀어서 설명해주면 좋겠다고 이 문서 보면서 한 100번은 생각한 거 같습니다.

우선 좀 풀어서 보겠습니다.

“대상 리소스가 요청에 포함된 표현을 처리”
- 요청에 포함된 표현이 무엇일까요? 이는 클라이언트가 서버에 전송하는 데이터입니다. 예를 들어, 폼 데이터, JSON 객체, 파일 등이 있겠죠??
- 대상 리소스는 서버에서 해당 요청을 처리할 특정 엔드포인트 또는 URI를 의미합니다. ‘/submit’, ‘/signup’, ‘/select/machines’ 이런 거 있겠죠??
“리소스 고유의 특정 시맨틱스에 따라 처리”
- 이 특정 시맨틱스는 대상 리소스가 데이터를 처리하는 고유한 방식 또는 논리를 의미합니다. 이는 각 서버나 어플리케이션이 POST 요청을 어떻게 해석하고 처리할지 정의하는 규칙입니다.
- 예를 들자면, 서버에서 ‘/signup’이라는 엔드포인트로 POST 요청이 들어오면 DB에 새로운 유저 레코드를 생성하는 경우와 ‘comment’라는 엔드포인트로 POST 요청이 들어오면 JSON 객체의 ‘id’ 필드에서 해당하는 게시물을 찾아 댓글을 새로 추가하는 등 서버가 정한 규칙에 따라 POST 요청을 처리하는 방식이 달라집니다.

그럼 이제 문서에선 4가지로 크게 구분하는 거 같은데 어떻게 사용되는지 확인해봅시다.

1. HTML 입력 폼 등을 이용한 데이터 처리 프로세스

POST는 우리가 주로 서버에 데이터를 보낼 때 사용합니다. 예를 들자면, 폼에 입력한 데이터를 서버로 전송할 때 사용되겠죠??

클라이언트가 회원 가입에 관련된 폼을 작성하고 제출하면, 해당 데이터는 POST 요청을 통해 서버로 전송됩니다.

POST /signup HTTP/1.1
Host: www.gojimin.com
Content-Type: application/json
Content-Length: 18

{
	"id": "jimin",
	"password": "secret"
}

2. 메세지 게시

POST는 게시판, 뉴스그룹, 메일링 리스트, 블로그 등과 같은 그룹에 메세지를 게시할 때 사용된다고 합니다. 제 블로그 게시물은 md 파일을 따로 올려서 게시하고 있기는 한데, 보통 웹 사이트에서 게시물 다 쓰고 ‘작성’ 버튼 누르면 해당하는 정보를 POST 요청으로 서버에 전송하는 것과 같습니다.

3. 새 리소스 생성

POST는 서버에서 아직 식별되지 않은 새로운 리소스를 생성하는 데에도 사용됩니다.

예를 들어, 우리가 쇼핑몰을 운영 중이라고 생각해봅시다. 이 때 새로운 상품을 추가할 때, 그 상품은 아직 서버에 없는 상태로 POST 요청을 통해 새 리소스가 생성됩니다.

POST /products HTTP/1.1
Host: www.gojimin.com
Content-Type: application/json

{
	"name": "완전 멋진 반바지",
	"price": 89000,
	"description": "어썸해요."
}

4. 기존 리소스에 데이터 추가

POST는 새로운 리소스 생성뿐만 아니라 기존의 리소스에 데이터를 추가하는 것도 가능합니다.

예를 들어, SNS 등에서 기존 게시물에 이용자가 댓글을 추가하는 것도 POST 요청을 통해서 기존 게시물에 추가하는 것입니다!

POST /comments HTTP/1.1
Host: www.gojimin.com
Content-Type: application/json

{
	"id": "해당 게시물 ID",
	"comment": "배고파요.",
	"createdAt": "2024-03-11"
}

헤더의 Location 필드

뜬금 없지만 이게 POST 요청의 응답 헤더에 포함되는 경우가 있어서 먼저 설명하고 가겠습니다.

‘Location’ 헤더 필드는 POST 요청의 응답에서 주로 리소스의 생성이나 리다이렉션과 관련된 상황에 사용됩니다.

어떤 역할을 가질까요?

1. 새로 생성된 리소스의 URI 제공에 사용됩니다.

서버가 클라이언트의 POST 요청을 처리해 새로운 리소스를 생성한 경우를 볼 수 있습니다.

예를 들어 이렇게 클라이언트가 새로운 데이터를 서버에 보낸다고 가정해봅시다.

POST /products HTTP/1.1
Host: www.gojimin.com
Content-Type: application/json

{
	"name": "완전 멋진 반바지",
	"price": 89000,
	"description": "어썸해요."
}

그럼 서버는 요청을 처리하고 새로운 리소스를 생성합니다. 이 경우에 서버는 상품 목록 DB에 새로운 상품 레코드를 추가하게 됩니다.

서버는 새로운 리소스 생성 후에 201 Created 상태 코드와 함께 ‘Location’ 헤더를 사용해 새로 생성된 리소스의 URI를 클라이언트에게 반환하게 됩니다. 상태 코드는 뒤에 설명하겠습니다.

HTTP/1.1 201 Created
Location: /products/411
Content-Type: application/json
Content-Length: 83

{
	"id": 411,
	"name": "완전 멋진 반바지",
	"price": 89000,
	"description": "어썸해요."
}

그럼 클라이언트는 ‘Location’ 헤더에 포함된 URI인 **‘products/411’**을 사용해 새로 생성된 리소스를 참조하거나 추가적인 작업을 수행할 수 있습니다. 예를 들어 해당 URI에 GET 요청을 보내서 상세 정보를 가져온다거나요!

2. 리다이렉션

서버가 클라이언트를 다른 URI로 리다이렉트 시키는 경우에 사용될 수 있습니다.

서버가 클라이언트의 요청을 처리한 뒤, 다른 리소스로 사용자를 안내해야되는 경우가 발생할 수 있습니다.

예를 들자면, POST 요청 후에 사용자를 결과 페이지로 안내하거나, 해당 리소스의 위치가 변경된 경우에 서버는 3XX 상태 코드와 함께 ‘Location’ 헤더를 설정해 클라이언트를 지정된 URI로 보낼 수 있습니다.

대표적으로 웹 사이트가 이전 됐을 경우에 사용되기도 합니다.

웹 사이트의 특정 페이지가 만약 새로운 URL로 이동되었다고 가정해봅시다. 이 경우 클라이언트가 이전 URL로 요청을 보냈을 경우, 서버는 클라이언트를 새로운 URL로 리다이렉트 시켜야 되겠죠?

단계별로 살펴봅시다!

클라이언트는 웹 사이트의 이전 URL로 접근을 시도합니다.

GET /jimin-old HTTP/1.1
Host: www.gojimin.com

서버는 요청된 페이지가 새로운 URL로 이동되었음을 알리고, 클라이언트를 새로운 URL로 리다이랙트합니다. 이를 위해 서버는 301 Moved Permanently 상태 코드와 함께 ‘Location’ 헤더를 설정해 응답합니다.

HTTP/1.1 301 Moved Permanently
Location: /jimin-new

클라이언트는 서버의 응답을 받아 ‘Location’ 헤더에 제공된 새로운 URL인 **‘/jimin-new’**로 자동으로 GET 요청을 보냅니다.

GET /jimin-new HTTP/1.1
Host: www.jimin.com

이제 서버는 새로운 페이지의 콘텐츠를 클라이언트에게 응답하게 됩니다.

아하 이제 Location 헤더는 서버가 클라이언트에게 새로 생성된 리소스의 URI를 제공하거나, 클라이언트를 다른 URI로 리다이렉트할 때 사용되는 것을 알았으니 이제 서버의 응답에 대해 살펴봅시다.

서버의 응답

위에서 확인한 결과 POST 요청은 서버에서 다양하게 처리될 수 있기 때문에 서버가 반환하는 응답도 다양합니다.

서버는 POST 요청을 처리한 결과에 따라 적절한 상태 코드를 선택해 응답하게 됩니다. 문서에선 거의 모든 상태 코드가 POST 응답으로 사용될 수 있는데, 일부 상태 코드인 206 Partical Content, 304 Not Modified, 416 Range Not Satisfiable은 사용되지 않는다고 합니다.

그럼 사용되는 상태 코드의 예시를 한번 확인해봅시다.

201 (Created):

해당 상태 코드는 새로운 리소스가 성공적으로 생성되었음을 나타내는 코드입니다.

HTTP/1.1 201 Created
Location: /products/411
Content-Type: application/json
Content-Length: 83

{
	"id": 411,
	"name": "완전 멋진 반바지",
	"price": 89000,
	"description": "어썸해요."
}

200 (OK) 혹은 204 (No Content):

요청이 성공적으로 처리 되었음을 나타내는 코드이며, 새로운 리소스가 생성되지는 않았음을 나타냅니다. 204는 응답 본문이 없습니다.

HTTP/1.1 200 OK
Content-Type: application/json

{
	"message": "데이터 잘 생성했어용."
}

혹은

HTTP/1.1 204 No Content

아하 이렇게 요청 처리 결과에 따라 다양하게 상태 코드를 반환할 수 있군요! 새로운 리소스가 생성되었다면 201 상태 코드가 사용되며, 생성된 리소스의 URI는 ‘Location’ 헤더에 포함되는 것을 알 수 있습니다. 만약 요청은 성공적으로 처리되었지만 새로운 리소스가 생성되지 않았다면 200또는 204 코드가 사용될 수 있음을 알았습니다!

POST도 캐싱이 될까요?

일반적으로 POST 요청에 대한 응답은 캐시되지 않습니다. 하지만! 문서에선 POST 요청에 대한 응답은 2가지 조건을 충족할 때만 캐시될 수 있다고 설명합니다.

명시적 캐시 허용

‘Cache-Control’ 또는 ‘Expires’ 헤더가 포함되어 있어야만 합니다. 저번 포스팅에서 다뤘죠?? 이 헤더들은 서버가 반환한 응답의 신선도를 나타내며, 이 캐시된 응답을 언제까지 신뢰할 수 있는지를 정의합니다.

Cache-Control: max-age=7200
혹은
Expires: Thu, 12 Sep 2024 11:21:00 GMT

Content-Location 헤더 필드를 포함

Content-Location 헤더는 해당 응답이 나타내는 리소스의 URI를 명시하는데 사용됩니다. 이 헤더는 응답이 가리키는 리소스의 실제 위치를 알려주는 역할을 합니다.
요약하자면 캐시되어야 하는 특정 리소스를 명확히 지정하기 위해 사용됩니다.
동일한 ‘Content-Location’을 갖는 GET 또는 HEAD 요청에서 재사용될 수 있습니다.

이렇게 2개의 조건을 충족시키면 POST의 응답도 캐시될 수 있다고 합니다.

그런데..POST의 응답이 캐시되는 경우에 대해 좀 알아봤는데 데이터 제출 중 API 요청의 반복 요청 방지 및 파일 업로드 간에 상태 확인 등에 사용된다고는 합니다..

근데 솔직히 반복 요청 방지는 버튼을 disabled 시키거나 로딩 스피너 띄우는데 굳이 할 필요가 있나? 싶습니다.

단순히 RFC 문서에서 언급된 내용은 POST 요청이 캐시될 수 있는 조건을 기술한 내용으로 일반적으로 POST의 응답이 캐시되는 경우는 없을듯합니다.

이전 포스팅에서도 정리했지만 POST 요청은 서버의 상태를 변경하는 안전하지 않은 메서드입니다. 근데 이게 캐싱되면 데이터 무결성과 일관성이 깨지지 않을까요?

그리고 POST 요청은 보통 서버의 상태를 변경 시키는데, 이 결과를 캐싱하면 상태 변화가 반영되지 않을 수 있을 거 같기도 합니다.

요약하자면..

POST는 서버에서 데이터를 처리하고, 새로운 리소스를 생성하거나 기존 리소스에 데이터를 추가하는데 사용되는 메서드입니다.

서버가 반환하는 응답의 상태 코드는 서버가 처리한 결과에 따라 달라집니다.

POST의 응답은 2가지 조건을 충족한다면 캐시될 수 있으며, 캐시된 응답은 후에 동일한 ‘Content-Location’을 갖는 GET, HEAD 요청에 사용될 수 있습니다.

마치며..

아니 GET, HEAD, POST만 정리했는데 너무 길어져서 또 끊어가려고 합니다.. 저도 제가 쓴 글 다시 보고는 하는데 너무 길면 읽다가 포기할 거 같더라구요..

RFC 문서 솔직히 불친절한 거 같습니다. ㅋ

짜증 제대로 나기는 하는데 뭐 시작한 이상 끝은 봐야되니까요… 오늘도 읽어주셔서 감사합니다.

뿅!

Prolip's Blog

시작..

GET

데이터 요청

캐싱

안전성과 멱등성

범위 요청

데이터 전송 방식

요약하자면

HEAD

응답 본문이 없습니다..

헤더 필드

보안적인 고려 사항?

요약하자면

POST

어떻게 사용될까요??

헤더의 Location 필드

서버의 응답

POST도 캐싱이 될까요?

요약하자면..

마치며..

HTTP Method가 뭔데요 (2)

HTTP Method가 뭔데요 (4)