Content Encoding 지원 추가

[eungjun-yi]

클라이언트가 요청해서 서버가 보내주어야 하는 리소스들은, 압축하면 크기가 줄어드는 경우가 많습니다.
jpg, png와 같은 이미지 파일들은 압축을 해도 큰 변화가 없겠지만, html, js, css 와 같은 종류의 파일들은 그 크기가 수분의 일에서 수십분의 일 까지도 줄어들 수 있을 것입니다.
우리 서버는 트래픽을 절약하기 위해 필요한 경우 리소스를 압축해서 보내줄 수 있어야 합니다.

방법은, Content-Encoding 헤더에 인코딩 방법을 적은 뒤 body에 그 인코딩 방법대로 리소스를 압축해서 보내주는 것입니다.

다만 사전에 어떤 인코딩 방법을 사용할지에 대해 서버와 클라이언트가 협상하여 결정할 필요가 있습니다. 이 과정을 "Content Negotiation"이라고 부릅니다.
허용되는 인코딩 방법을 서버가 알려주고 클라이언트가 선택하는 방법을 Client-Driven Negotiation이라고 하며, 반대로 클라이언트가 선호하는 인코딩을 알려주고 서버가 결정하는 방식을 Server-Driven Negotiation이라고 합니다. 또한 이 둘을 혼합하는 방식도 있는데, 그것은 Transparent Negotiation이라고 부릅니다.

참고자료: RFC 2616 3.5 Content Coding, 12. Content Negotiation

[rampart81]

@npcode Content Encoding 방식에 대해서 제가 제대로 이해 했는지 확인 하고자 합니다. 클라이언트 가 Accept-Encoding 헤더 를 통하여 원하는 압축방식 들을 보내주면 서버는 클라이언트가 지원하는 요청방식중 서버가 지원 가능한 압축방식 을 결정해 그 방식으로 압축한후 Content-Encoding 헤더를 통해 사용된 압축방식을 알으켜주는것이죠? 즉

Accept-Encoding: gzip, deflate (클라이언트) <==> Content-Encoding: gzip (서버)

제가 잘 이해한건가요?

[eungjun-yi]

@rampart81 넵 맞습니다.

주의하실 점은,

1. q 파라메터를 파싱해야 한다는 점. q값은 0.000부터 1.000까지 가능하며(소수점 세자리까지 사용가능) 이 값에 의해 우선순위가 결정됩니다. 예) "Accept-Encoding: gzip; q=0.7, deflate; q=0.8" 라면 deflate가 우선순위가 높음
2. q 파라메터가 지정되지 않은 경우, 순서는 우선순위와 아무 관련이 없습니다. 예) "Accept-Encoding: gzip, defalte"는 gzip이 deflate보다 우선순위가 높다는 의미가 아님.
3. 2에도 불구하고, q 파라메터가 없는 경우에 순서를 우선순위로 간주하는 클라이언트가 있을 수 있습니다. 따라서 q 파라메터가 없을 때는 그냥 순서를 우선순위로 가정하고 처리하는 것이 좋습니다. 그렇게 한다고 해서 스펙을 위반하는 것은 아니기 때문입니다.

[rampart81]

@npcode 아 그렇군요! q 파라메터 에 대해서는 몰랐네요! 자세한 답변 감사드립니다 ^^

[eungjun-yi]

@rampart81 q 파라메터는 값을 목록 형태로 갖는 헤더들에서 널리 쓰이는데, HTTP 헤더 파싱을 까다롭게 만드는 원인 중 하나죠. 한번 잘 만들어두면 두고두고 편할 것 같아요.

[eungjun-yi]

Content Negotiation도 사실 Content-Encoding 에서만 쓰는게 아니라, Content-Charset, Content-Type, Content-Language 에서도 쓰입니다. 다 똑같은 방식으로요. :)

[eungjun-yi]

아 그리고 만약 클라이언트가 요청한 Encoding으로 응답을 생성할 수 없다면, 415 Unsupported Media Type으로 응답하시면 됩니다.

[rampart81]

@npcode 아 알겠습니다 ^^ 그럼 q 파라메터 파서 를 다른곳에서도 쓰일수 있도록 해야겠네요! ^^

[rampart81]

@npcode q 파라메터 가 있는 헤더와 없는 헤더가 섞여있으면 어떻게 처리하나요? 예를 들어,

"Accept-Encoding: gzip; q=0.7, deflate"

이면 BadRequest 를 리턴해야 하나요 아니면 q 파라미터를 있는 포멧은 우선순위로 둬야하는건가요?

그리고 HttpResponse 파일이 너무 거대해져서 더 세분화 시켜서 나눌려고 하는데, 혹시 지금 하시는 task 와 conflict 있을지 궁굼하네요.

[eungjun-yi]

아 제가 아주 중요한 것을 빠뜨렸었군요. 잘 짚어주셨습니다.

q파라메터의 디폴트값은 1입니다. 따라서 q 파라메터가 없는 것은 q파라메터가 1인 것과 같습니다.

드신 예에서는 deflate가 가장 높은 우선순위를 갖습니다.

1. 2. 13. 오전 4:35 Eun Woo Song notifications@github.com 작성:

@npcode q 파라메터 가 있는 헤더와 없는 헤더가 섞여있으면 어떻게 처리하나요? 예를 들어,

"Accept-Encoding: gzip; q=0.7, deflate"

이면 BadRequest 를 리턴해야 하나요 아니면 q 파라미터를 있는 포멧은 우선순위로 둬야하는건가요?

그리고 HttpResponse 파일이 너무 거대해져서 더 세분화 시켜서 나눌려고 하는데, 혹시 지금 하시는 task 와 conflict 있을지 궁굼하네요.

—
Reply to this email directly or view it on GitHub.

[eungjun-yi]

@rampart81 conflict 걱정은 안 하셔도 될 것 같습니다. 제가 요새 회사에서 HTTP 교육 준비 때문에 다른 일을 거의 못 하고 있어서;;

[nephilim]

Caching 이슈와도 관련이 있는데, Vary 헤더 처리도(Vary: Accept-Encoding) 해주면 좋을 것 같습니다. 재밌어보여 끼어들고파서 지나가다 휙~ 하나 남겨봐요.

[eungjun-yi]

@nephilim 아, 모르고 있었는데 cachable한 response는 Vary 헤더를 꼭 추가해야(SHOULD) 하는군요. 알려주셔서 고맙습니다. #1 에 추가해야 할 것 같네요. 해결도 거기서 하는 것이 좋겠어요.

[rampart81]

@npcode 네 자세한 답변 감사합니다 ^^
@nephilim 좋은 정보 감사합니다 ^^

[rampart81]

이 Task 아직 끝나지 않았는데 close 가 됬네요 ^^
다시 open 부탁드립니다~