직장에 있는 Windows 7 64비트 PC에 이상한 문제가 있습니다. 나는 gzip으로 압축된 콘텐츠(js, css, html)를 제공하는 몇 가지 Linux 웹 서버를 관리합니다. 이상한 동작은 내 시스템(Firefox, Chrome, Vivaldi)의 모든 브라우저가 해당 Linux 서버에서 콘텐츠를 요청할 때(헤더는 잘 보입니다 Accept-Encoding: gzip,deflate) 이를 얻지 못한다는 것입니다. 모든 응답에는 가 포함되어 있으므로 Transfer-Encoding: chunked콘텐츠가 압축되어 제공되지 않습니다. 그러나 옵션을 curl사용하여 명령줄에서 실행하면 --compressed응답이 헤더 Content-Type: gzip와 함께 제공되며 Content-Length예상대로 gzip으로 압축됩니다. Windows 2008 R2 서버에서는 콘텐츠가 gzip으로 압축되어 제공됩니다.
콘텐츠를 gzip으로 압축하여 제공하면 해당 Linux 웹 서버에서 제대로 작동합니다. 이는 보장됩니다.
pfSense 프록시가 관련되어 있지만 브라우저가 Linux 서버에서 직접 콘텐츠를 요청하도록 프록시 설정에서 이를 재정의하더라도 동작은 동일합니다. 프록시 유무에 관계없이 변경 사항이 없습니다.
다른 Windows 7 64비트 PC에서 Firefox 및 Chrome의 문제를 확인했습니다. 그래서 저는 이 이상한 브라우저 동작에 OS가 어떻게든 관련되어 있다는 결론에 도달했습니다.
누가 확인해 주실 수 있나요...?
답변1
이것은 속일 수 있습니다. gzip으로 압축된 파일을 하나의 메시지로 보내려면 서버가 전체 파일을 사용할 수 있어야 하고 해당 크기를 알아야 합니다. 이는 귀하가 직접 말한 것처럼 귀하의 경우에는 발생하지 않는 것 같습니다.
옵션 을 사용하여 명령줄에서 컬을 실행하면
--compressed응답Content-Type: gzip과Content-Length헤더가 함께 제공되며 예상대로 gzip으로 압축됩니다.
내 생각에 귀하의 경우에는 서버파이프출력을 gzip으로 변환한 다음 파일 크기를 계산하기 위해 먼저 데이터를 디스크에 쓰지 않고 결과를 브라우저에 직접 파이프합니다. 크기를 미리 알지 못하기 때문에 서버는 Transfer-Encoding: chunked사용 가능한 만큼의 부분이 포함된 스트림을 반환할 수밖에 없습니다 .
데이터를 사용할 수 있게 되면 청크로 반환되어 브라우저에서 다시 조립됩니다. 그러나 수신된 데이터는 청크로 수신되더라도 여전히 gzip으로 압축됩니다.