Hi Baptiste,

On Mon, Aug 12, 2019 at 09:35:56PM +0200, Baptiste wrote:
> The use case is to avoid too many requests hitting an application server
> for "preflight requests".

But does this *really* happen to a point of being a concern with OPTIONS
requests ? I mean, if OPTIONS represent a small percentage of the traffic
I'd rather not start to hack around the standards and regret in 2 versions

> It seems it owns its own header for caching:
> https://www.w3.org/TR/cors/#access-control-max-age-response-header.
> Some description here: https://www.w3.org/TR/cors/#preflight-result-cache-0

But all this spec is explicitly for user-agents and not at all for
intermediaries. And it doesn't make use of any single Cache-Control
header field, it solely uses its own set of headers precisely to
avoid mixing the two! And it doesn't suggest to violate the HTTP

> 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.

I still feel extremely uncomfortable with this because given that it
requires to violate the basic standards to achieve something that is
expected to be normal, that smells strongly like there is a wrong
assumption somewhere in the chain, either regarding how it's being
used or about some requirements.

If you don't mind I'd rather bring the question on the HTTP working
group to ask if we're missing something obvious or if user-agents
suddenly decided to break the internet by purposely making non-
cacheable requests, which is totally contrary to their tradition.

As you know we've known a period many years ago where people used
to say "I inserted haproxy and my application stopped working". Now
these days are over (the badmouth will say haproxy stopped working)
in main part because we took care of properly dealing with the
standards. And clearly I'm extremely cautious not to revive these
bad memories.


Reply via email to