[
https://issues.apache.org/jira/browse/TS-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813976#comment-13813976
]
ASF subversion and git services commented on TS-2245:
-----------------------------------------------------
Commit 70815db3b237d5e572ff9bc0a4df81d64157ba92 in branch refs/heads/master
from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=70815db ]
TS-2245 This adds a '2' config state to the ignore mismatch configs
This is completley backwards compatible, but adds a new feature which
allows a much more sane behavior for these configs:
proxy.config.http.cache.ignore_accept_mismatch
proxy.config.http.cache.ignore_accept_language_mismatch
proxy.config.http.cache.ignore_accept_encoding_mismatch
proxy.config.http.cache.ignore_accept_charset_mismatch
Setting any of these to the value '2' will now ignore the
respective client request header, but *only* if the cached
response does not have a Vary: header.
The old documentation seemed to imply that this would be
the case, but it was never so. Setting any of these to "1"
would simply ignore whatever the Vary: header says.
> Fix the semantics and behavior of e.g.
> proxy.config.http.cache.ignore_accept_encoding_mismatch
> ----------------------------------------------------------------------------------------------
>
> Key: TS-2245
> URL: https://issues.apache.org/jira/browse/TS-2245
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Fix For: 4.1.0
>
>
> These four configurations options where added to fix a real problem (content
> duplications in cache):
> {code}
> {RECT_CONFIG, "proxy.config.http.cache.ignore_accept_mismatch", RECD_INT,
> "0", RECU_DYNAMIC, RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
> ,
> {RECT_CONFIG, "proxy.config.http.cache.ignore_accept_language_mismatch",
> RECD_INT, "0", RECU_DYNAMIC, RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
> ,
> {RECT_CONFIG, "proxy.config.http.cache.ignore_accept_encoding_mismatch",
> RECD_INT, "0", RECU_DYNAMIC, RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
> ,
> {RECT_CONFIG, "proxy.config.http.cache.ignore_accept_charset_mismatch",
> RECD_INT, "0", RECU_DYNAMIC, RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
> ,
> {code}
> However, as implemented, they are pretty much useless, and if enabled, have
> high risk of giving wrong content. To make things worse, they are global
> configurations, since they are not passable from the HTTPSM into the cache.
> I've examine the code thoroughly, and I actually think these configurations
> had the right intentions, but just implemented it wrong. What they really
> ought to have been is e.g.
> proxy.config.http.cache.relax_accept_encoding_match .
> What *should* happen (IMO) is that these four configs (ideally we'd rename
> them or make new ones) would check if there is no Vary: header in the cached
> entry. IF there is no Vary: header, *AND* one of these settings it set, we
> skip that matching that happens on the cache client header and the incoming
> client header entirely (give the match a score of 1.0). These configs should
> ideally also be per-remap overridable, but that requires code changes like
> TS-1919.
> A real use case scenario is this: Assume a content is always served by origin
> without Content-Encoding, or Vary: header. This would be typical for e.g. a
> PNG (image).
> Upon cache miss, if the first request comes with Accept-Encoding: gzip,
> everything is fine, and we serve this cached item to all clients thereafter.
> However, if the first request comes with no Accept-Encoding: header
> whatsoever, that response can not satisfy a response from a request with AE:
> gzip, so we get *at least* two copies of the same object in cache.
> I'm curious to get some input on this, and let me know if the explanations
> makes no sense. :)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
