- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 17 Oct 2007 01:14:46 +0000 (UTC)
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: "WAF WG (public)" <public-appformats@w3.org>
On Tue, 16 Oct 2007, Henri Sivonen wrote: > > > > We can't use OPTIONS because Apache returns > > > > Allow: GET,HEAD,POST,OPTIONS,TRACE > > > > ...by default, which would basically mean that out of the box, any > > resource that support cross-site GET would automatically support > > cross-site POST. > > This could be remedied by using a newly named header in the OPTIONS > response (e.g. Method-Allow). As a further benefit, introducing new > headers would allow the caching outlined in Anne's message. I have no objections to new headers. > > Also, OPTIONS doesn't return a body, which is useful to authors who > > want to include the cross-domain rights in XML PIs rather than HTTP > > headers. > > Do bad things happen if you do return an entity body in an OPTIONS > response? I can't work out how to return _anything_ from a CGI script with OPTIONS. The script doesn't seem to get called (using Apache). I'm probably doing something wrong, but, as I noted in my reply to Bjoern, this is a security issue -- we want the bar to be so low, that even people who don't really know what they're doing will still end up safe. > Moreover, what's the point of using PIs if you have control over HTTP > headers? I think consistency is key here -- if we allow PIs in one area, they should work everywhere. Again, security APIs need to be as obvious and unsurprising as possible. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 17 October 2007 01:14:58 UTC