[
https://issues.apache.org/jira/browse/TS-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802977#comment-13802977
]
Leif Hedstrom commented on TS-2245:
-----------------------------------
I'm thinking we could turn the existing configuration options to trie-state
configs:
0 - Client header is used / honored even in the absence of Vary: header from
origin (this is default behavior)
1 - Client header is never used when performing the default alternate
selection. [This is useless IMO, but supported now].
2 - Client header is not used in alternate selection if there is no Vary: from
origin specifying to use it.
2 would be a useful option for most reverse proxies, and should be safe.
In addition, I'd really like to see these overridable per remap rule, but
that's not currently possible to implement. It'd be possible as 5.0.x branch is
currently, but odds are that we'll have to back out those changes since there's
objections to that patch from the Cache Cluster people (see TS-1919).
> 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: 6.0.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)
