Re: CORS performance proposal

Picking up an old thread...

On 20 Feb 2015, at 12:54 pm, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> 
> * Martin Thomson wrote:
>> On 20 February 2015 at 11:39, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>>> The proposal is to use `OPTIONS * HTTP/1.1` not `OPTIONS /x HTTP/1.1`.
>> 
>> I missed that.  In which case I'd point out that `OPTIONS *` is very
>> poorly supported.  Some people (myself included) want it to die a
>> flaming death.
> 
> Evidence for "poorly supported" would certainly be helpful (web hosting
> packages without TLS support, for instance, do not count, though).

FWIW, this is old but I think still true, at least regarding OPTIONS *:
  https://www.mnot.net/blog/2005/04/03/options

I wrote up my thoughts about using OPTIONS after looking at it for many years:
  https://www.mnot.net/blog/2012/10/29/NO_OPTIONS

Also - it's becoming more common for content providers to ask CDNs for CORS preflight caching. Since OPTIONS doesn't fit into HTTP caching, something custom has to be designed, which means dealing with all of the corner cases, interop issues, etc. 

Using a .well-known would avoid all of that, since it can be cached just like any other response. If there's concern about extra requests against origins that don't use this mechanism, I'd suggest defining a default cacheability for 404 responses on the resource (e.g., 3 hours). That said, I suspect that if this were defined, take-up would be good; it's much easier than supporting pre-flights.

A header denoting site-wide metadata would work for this too, of course, if folks were comfortable with the security properties of doing that (as well as the potential response overhead). 

Cheers,

--
Mark Nottingham    mnot@akamai.com    https://www.mnot.net/

Received on Tuesday, 9 June 2015 04:31:10 UTC