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 later... > 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 standards. > 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. Thanks, Willy