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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 19 Dec 2007 14:39:48 +0100
Message-ID: <47691F24.1060106@gmx.de>
To: Anne van Kesteren <annevk@opera.com>
CC: Jonas Sicking <jonas@sicking.cc>, "public-html@w3.org" <public-html@w3.org>

Anne van Kesteren wrote:
> On Tue, 18 Dec 2007 09:18:26 +0100, Julian Reschke 
>> But saying something is going to profile HTTP. This may or may not be 
>> a useful extension point, and it shouldn't be closed down by this WG. 
>> Please leave HTTP questions to the HTTP working group.
> If this is later overridden by HTTP and implementors actually change 
> their implementations to allow that we can always change the 
> XMLHttpRequest specification. For now GET requests will never have an 
> entity body. This was only needed for GET requests, right?

RFC2616 currently doesn't say (and that's why it is an open issue), so 
you can't really say that.

>> What's next? Disallowing non-RFC2616 methods because Opera screws them 
>> up? Why not fix the implementations instead?
> In this case it's not clear that the implementations are broken given 
> that they all do it in the same way and all would like to remain doing 
> so it seems. Also, as Jonas points out there's a cross-site risk 

As far as I can tell, this is incorrect. Except for Opera, all 
implementations either support arbitrary methods (IE6/MSXML, Firefox) or 
reject the request (IE7, Safari3?). It's only Opera which still silently 
rewrites method names.

> involved in case of XMLHttpRequest Level 2. I haven't yet updated 
> XMLHttpRequest Level 2 to keep it stable while we work out the First 
> Public Working Draft details.

BR, Julian
Received on Wednesday, 19 December 2007 13:40:04 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:29 UTC