🎯 Goals
HTTP Request 다음 헤더를 뜯어본다.
- Content-Type
- Accpet
- Vary
Content-Type
Request 에서의 Content-Type
클라이언트가 서버에게 실제로 보내는 타입이 뭔지 알려줌. (확정)
Response 에서의 Content-Type
서버가 클라이언트에게 실제로 보낸 페이로드의 타입이 뭔지 알려줌 (확정)
Accept
Request 에서의 Accpet
"서버야, 나에게 반환할 형태를 이 중에 골라"
Accept: text/html, application/json나는 text/html, application/json 만 이해할 수 있으니
Content-Type: text/html 또는
Content-Type: application/json 을 반환해.
Response 에서의 Accept
없음.
Content negotiation
HTTP에서 리소스의 형태를 결정하는 메커니즘
user 가 어느 형태가 적합한지 명시함.
동일한 URL 요청이라 하더라도 반환되는 파일의 형태가 다를 수 있는 이유.
The server uses content negotiation to select one of the proposals and informs the client of the choice with the
Content-Typeresponse header. - MDN Docs
Request example
GET /URL HTTP/1.1
Accept: text/*👉🏻 서버야 내가 이해할 수 있는건 text/* 시리즈야.
Respons example
HTTP/1.1 200 OK
✅ "text/*" 중에 골라서 리턴
Content-Type: text/html || Content-Type: text/pdfGET [URL] => return text/html || text/pdf || gzip
Vary
무엇을 서버가 고민해왔는가 미리 올려놓고 캐시 처리를 위한 것.
Method , URL 을 제외한 다른 어떤 요소 (보통은 헤더)가 content of response 에 영향을 미치는지 명시
example
Vary: Origin
👉🏻 Origin 헤더가 동일할 경우 같은 `Content-Type` 에 같은 리소스를 캐싱하여 응답Error case study
다음 요청-응답 사례를 보고 해석해보자.
HTTP Request headers
Content-Type: multipart/form-data; boundary=<calculated when request is sent>
Accept: */*
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Type: text/csvHTTP 415 Error Response
{
"statusCode": 415,
"code": "FST_ERR_CTP_INVALID_MEDIA_TYPE",
"error": "Unsupported Media Type",
"message": "Unsupported Media Type: text/csv"
}에러 해석
서버의 미들웨어에서는
multipart/form-data로 Content-Type 을 강제해놓고
request Contet-Type은text/csv로 설정
=> Content negotiation 매커니즘에 의해 415 에러 메시지 반환.
📝 Summary
| Index | Content-Type | Accept |
|---|---|---|
| Client | In request, What type of data is actually sent | Inform to server that client can understand what type of contents in response |
| Server | In response, what the content type of returned content actually is | X |
🔗 Reference
