[
https://issues.apache.org/jira/browse/TS-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15425065#comment-15425065
]
Bryan Call commented on TS-4275:
--------------------------------
Does the ETag header need to change if the Content-Encoding changed?
> gzip plugin modifies the ETag in a way that makes INM requests from ATS
> useless
> -------------------------------------------------------------------------------
>
> Key: TS-4275
> URL: https://issues.apache.org/jira/browse/TS-4275
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
> Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> When we transform the object to be gzip'ed, we (currently) append a -df to
> the ETag string. That seems somewhat reasonable, since the object has
> changed, the ETag should not be the same (they are two distinguishable
> objects).
> However, when we (now) go to origin on a stale-hit (cached but expired), we
> send a request like
> {code}
> If-None-Match: "8de5-52c99d55fd840-df"
> {code}
> But, this is never a match, since the Origin's ETag is
> {code}
> ETag: "8de5-52c99d55fd840"
> {code}
> Otto suggested changing this to a weak ETag, but not 100% sure if that's good
> enough. Another option is to save/restore the ETag before doing the INM
> request, but not sure if that's 100% safe either?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
