- From: Joseph A Holsten <joseph@josephholsten.com>
- Date: Fri, 23 Oct 2009 04:30:07 -0500
- To: Roy T. Fielding <fielding@gbiv.com>
- Cc: Eran Hammer-Lahav <eran@hueniverse.com>, Dan Connolly <connolly@w3.org>, www-tag@w3.org
Roy T. Fielding supposedly wrote: > On Oct 22, 2009, at 3:48 PM, Eran Hammer-Lahav wrote: > >> When I did my survey last year for possible solutions, the issues >> raised about OPTIONS were lack of support/understanding in many web >> environments and hosting services, no caching, and the need to >> define a syntax for the OPTIONS response in addition to that of the >> metadata document. Of all these, the difficulty in deployment on >> both the server and client side (unfortunately) prevents OPTIONS >> from being used in most web protocols. > > Ugh. If I had an example of what needs doing, I could make > sure it works on Apache. Most things can be configured like > > SetEnvIf Request_Method OPTIONS do_options_stuff=y > Header add Link '</favicon.ico>;rel="icon"' env=do_options_stuff Which is lovely for us, but most of the world still chooses to suffer with shared hosting. And plenty access the web through broken proxies. And yahoo cries itself to sleep when things can't be cached. So, the justification was for an idiot-proof alternative to OPTIONS, with caching. Short of paying for everyone's hosting, teaching them apache configs, replacing their other broken software, and paying for every OPTIONS request that yahoo wishes could be cached, I don't know how to fix it. Well-known seems to be the worst solution to this problem, except for everything else. BTW, mnot has been trying to make OPTIONS work for a while: http://www.mnot.net/blog/2005/04/03/options -- Joseph Holsten http://josephholsten.com
Received on Friday, 23 October 2009 09:30:43 UTC