关于nginx的Etag问题,nginx默认是有Etag的,但是问题就在于:无论你对源代码做了什么改动,比如说改动了注释,改动了空行什么的,ETag都会变。
(但实际上,比如我改动了注释,但是这个注释可能对程序员很重要,对用户来讲是无所谓的,因此ETag是没有必要变化的)
而http权威指南中说Etag解决了这个问题:
有些文档可能被修改了,但所做修改并不重要,不需要让世界范围内的缓存都重装数据(比如对拼写或注释的修改)。
而nginx默认也加了前缀“W/”来标识弱验证器
那这样的话ETag显然没有解决这个问题。
由于笔者对nginx停留在仅供使用的阶段,并没有源码查看和插件编写的经历,所以想问:
nginx有没有办法配置或者现成的插件或者自定义增加一些内容,从而让ETag并不是任意更改都变化,有一定的变通性?或者说 nginx有没有办法自定义ETag的生成规则?
天蓬老师2017-04-17 16:00:54
이를 nginx로 제어하지 않는 것이 가장 좋습니다. 자동화된 빌드 중에 제어할 수 있습니다. 예를 들어 webpack은 패키징할 때 모든 주석을 제거합니다. 또한 ETag를 통해 캐싱을 협상하지 말고, webpack을 통해 해시를 설정하여 캐싱을 강제합니다.
추가: Etag를 사용하면 어떨까요
귀하께서 기재하신 상황
협상 캐시에는 304가 필요하지만 여전히 요청을 보내야 합니다
로드 밸런싱 중에 서로 다른 물리적 시스템에 있는 동일한 파일의 서로 다른 inode가 서로 다른 ETag를 생성합니다(테스트되지 않음)
참고: 구성 오류로 인한 차이: 200 OK(FROM CACHE) 및 304 NOT MODIFIED
高洛峰2017-04-17 16:00:54
올바른 접근 방식은 파일이 수정되었는지 확인하기 위해 etag에 의존하지 않는 것입니다.
정적 파일 캐싱 문제를 해결하려면 브라우저가 링크가 변경된 것으로 간주하고 최신 버전의 파일을 다시 요청하도록 웹 링크에 특수 요청 매개변수를 추가해야 합니다.
etag 변경 없이 주석을 수정하려면 프런트엔드 자동화 프로세스를 구성하고, 프로덕션 환경에서 실행 중인 코드를 개발 코드에서 분리한 다음, 주석이 달린 코드를 원클릭으로 압축하고 난독화해야 합니다. 프로덕션 환경에 게시