On Mon, Aug 12, 2019 at 8:14 AM Willy Tarreau <w...@1wt.eu> wrote:

> Guys,
> On Wed, Aug 07, 2019 at 02:07:09PM +0200, Baptiste wrote:
> > Hi Vincent,
> >
> > HAProxy does not follow the max-age in the Cache-Control anyway.
> I know it's a bit late but I'm having an objection against this change.
> The reason is simple, OPTIONS is explicitly documented as being
> non-cacheable : https://tools.ietf.org/html/rfc7231#section-4.3.7
> So not only by implementing it we're going to badly break a number
> of properly running applications, but in addition we cannot expect
> any cache-control from the server in response to an OPTIONS request
> precisely because this is forbidden by the HTTP standard.
> When I search for OPTIONS and cache on the net, I only find AWS's
> Cloudfront which offers an option to enable it, and a number of
> feature requests responded to by "don't do that you're wrong". So
> at the very least we need to disable this by default, and possibly
> condition it with a well visible option such as "yes-i-know-i-am-
> breaking-the-cache-and-promise-never-to-file-a-bug-report" but what
> would be better would be to understand the exact use case and why it
> is considered to be valid despite being a blatant violation of the
> HTTP standard! History tells us that purposely violating standards
> only happens for bad reasons and systematically results in security
> issues.
> Thanks,
> Willy

Hi Willy,

The use case is to avoid too many requests hitting an application server
for "preflight requests".
It seems it owns its own header for caching:
Some description here: https://www.w3.org/TR/cors/#preflight-result-cache-0

I do agree we should disable this by default and add an option
"enable-caching-cors-responses" to enable it on demand and clearly state in
the doc that this is not RFC compliant.
Let me know if that is ok for you.


Reply via email to