Picking up an old thread...

On 20 Feb 2015, at 12:54 pm, Bjoern Hoehrmann <derhoe...@gmx.net> wrote:
> * Martin Thomson wrote:
>> On 20 February 2015 at 11:39, Bjoern Hoehrmann <derhoe...@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 *:

I wrote up my thoughts about using OPTIONS after looking at it for many years:

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 

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


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

Reply via email to