W3C home > Mailing lists > Public > public-webapi@w3.org > December 2007

Re: [XHR] send doesn’t explain what to do when method is GET

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Fri, 21 Dec 2007 09:45:49 +1100
Cc: Julian Reschke <julian.reschke@gmx.de>, Anne van Kesteren <annevk@opera.com>, Maciej Stachowiak <mjs@apple.com>, Mark Baker <distobj@acm.org>, Boris Zbarsky <bzbarsky@mit.edu>, Bjoern Hoehrmann <derhoermi@gmx.net>, public-webapi@w3.org
Message-Id: <6CDF08F7-9A80-4D5A-B820-C2E15B10CFCE@yahoo-inc.com>
To: Jonas Sicking <jonas@sicking.cc>




On 2007/12/18, at 12:43 PM, Jonas Sicking wrote:

> Julian Reschke wrote:
>> Jonas Sicking wrote:
>>>> Disagreed. Please do not try to standardize HTTP APIs that  
>>>> profile what HTTP allows.
>>>
>>> XHR already disallows a lot of things that HTTP allows. Setting  
>>> certain headers, cross site requests, etc. Why is this different?
>> XHR should only disallow things when there's a good reason to do  
>> so, that is, when the fact that XHR requests can be invoked by  
>> client-side script in HTML pages affects the security picture.
>> I don't see what that would have to do with GET bodies.
>
> Interoperability is IMHO a pretty good reason.

Yes, but not by profiling down the spec arbitrarily.

> I can't say I care super much, but I still don't see any value in  
> allowing bodies with GET requests.

The TAG and others have often talked about using GET on bodies. Not  
many people are doing it now (I have seen a few, under controlled  
conditions), but they very well may want to in the future.

Cheers,


--
Mark Nottingham       mnot@yahoo-inc.com
Received on Thursday, 20 December 2007 22:46:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:59 GMT