Bring up the subject again. I do think that having <If> and <RewriteCond> behaving in the same way when setting the Vary headers would be really important, but I am not sure if this is a 2.5.x only change or if it is worth to break the existing 2.4 behavior. Thoughts?
To summarize the current behavior: 1) <If HeaderFoo condition> sets Vary:HeaderFoo to the response regardless of condition being true or false. 2) RewriteCond HeaderFoo condition sets Vary:HeaderFoo only when condition is true (we state it very clearly in the docs). Luca 2017-10-27 18:48 GMT+02:00 Luca Toscano <[email protected]>: > Took a look to the following docs: > > https://docs.trafficserver.apache.org/en/5.3.x/admin/ > http-proxy-caching.en.html > https://varnish-cache.org/docs/5.1/users-guide/ > increasing-your-hitrate.html > https://www.fastly.com/blog/best-practices-using-vary-header/ > > The last one contains an interesting bit: "Vary to the Rescue" (the > Vary:Accept-Encoding header example). > > It seems to me that almost all caches expand their caching keys with > whatever header is added to "Vary". From the example that I've read, the > only fact that a response for the URI /foo/bar may be different if > Header:something is present or not in the request indicates a good use case > for adding Vary:something to the response. For a caching proxy in fact the > absence of a Header will become part of a key: > > URI x + no Header:something --> cached object 1 > URI x + Header:something=foo -> cached object 2 > URI x + Header:something=bar -> cached object 3 > etc.. > > The fine tuning of this behavior to avoid cache pollution or a low hit > rate can be controlled in RewriteConds via the NV (no-vary) configuration, > so it shouldn't be a big issue. I am more convinced that the <If> behavior > is the right one to follow.. > > Luca > > > > 2017-10-25 23:08 GMT+02:00 Luca Toscano <[email protected]>: > >> Hi Ruediger, >> >> the following patch (still to be carefully tested and/or improved) should >> force RewriteCond to behave like an <If> block adding the Vary header >> simply if the condition is evaluated (so header value present in the >> request but not satisfying the condition or header completely absent): >> >> http://home.apache.org/~elukey/httpd-trunk-mod_rewrite-add_ >> vary_header_always.patch >> >> It seems to be a big change in behavior though, I'd be curious to find >> out the motivations of the implementation choice at the time (will try to >> dig a bit into svn history). >> >> Thanks! >> >> Luca >> >> 2017-10-23 8:43 GMT+02:00 Plüm, Rüdiger, Vodafone Group < >> [email protected]>: >> >>> I would tend to say that the <If> code is correct and the RewriteCond >>> code is wrong, because it doesn’t matter if the condition becomes true or >>> false. The headers value has an influence on the result. Tricky question is >>> what to do regarding Vary if the non-presence of a header has an influence. >>> >>> >>> >>> Regards >>> >>> >>> >>> Rüdiger >>> >>> >>> >>> *Von:* Luca Toscano [mailto:[email protected]] >>> *Gesendet:* Sonntag, 22. Oktober 2017 11:47 >>> *An:* Apache HTTP Server Development List <[email protected]> >>> *Betreff:* Re: mod_rewrite, vary headers and internal redirects >>> >>> >>> >>> Hi everybody, >>> >>> >>> >>> 2017-10-09 13:46 GMT+02:00 Luca Toscano <[email protected]>: >>> >>> Hi Yann, >>> >>> >>> >>> 2017-10-08 14:13 GMT+02:00 Yann Ylavic <[email protected]>: >>> >>> On Sun, Oct 8, 2017 at 2:03 PM, Yann Ylavic <[email protected]> >>> wrote: >>> > Hi Luca, >>> > >>> > On Sun, Oct 8, 2017 at 11:59 AM, Luca Toscano <[email protected]> >>> wrote: >>> >> >>> >> Does this approach make sense? Is there any smarter way to do it? >>> > >>> > I can't tell that I love the hack in internal redirects but looks like >>> > a simple way to handle the case... >>> > Nit: maybe a more descriptive name for the "keep-vary-header" note, >>> > "redirect-keeps-vary"? >>> >>> >>> >>> +1 >>> >>> >>> >>> >>> But after all, if we reach an internal redirect with some Vary header >>> already set, maybe we should never drop it, thus internal redirects >>> should preserve Vary in any case... >>> >>> >>> >>> I'd prefer to limit the scope of the httpd configurations affected by >>> this change to the minimum, but the change would probably look less hacky :) >>> >>> >>> >>> >>> >>> After https://svn.apache.org/r1811744 trunk should be inline with what >>> the docs say, but I have another question now: a RewriteCond condition >>> (containing something like HTTP:someheader) adds a Vary header to the >>> response only if the condition evaluates to true, meanwhile a <If> >>> condition adds the Vary header regardless. Is there any good motivation for >>> this difference or they should be modified to be more consistent? The <If> >>> block behavior seems to be more sound (after reading >>> https://tools.ietf.org/html/rfc7231#section-7.1.4), but I'd like to >>> hear more expert opinions :) >>> >>> >>> >>> Thanks! >>> >>> >>> >>> Luca >>> >> >> >
