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: Anne van Kesteren <annevk@opera.com>
Date: Wed, 19 Dec 2007 14:36:51 +0100
To: "Julian Reschke" <julian.reschke@gmx.de>, "Jonas Sicking" <jonas@sicking.cc>
Cc: "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.t3k33pu764w2qv@annevk-t60.oslo.opera.com>

On Tue, 18 Dec 2007 09:18:26 +0100, Julian Reschke <julian.reschke@gmx.de>  
> Jonas Sicking wrote:
>> But not saying anything is likely to hurt compatibility between  
>> implementations and make authors rely on features that only work in  
>> some browsers.
> 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?

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

Anne van Kesteren
Received on Wednesday, 19 December 2007 13:35:58 UTC

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