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