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

(wrong string) €™t explain what to do when method is GET

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Thu, 13 Dec 2007 03:58:34 +0100
To: "Anne van Kesteren" <annevk@opera.com>
Cc: public-webapi@w3.org
Message-ID: <qo21m39queuqgogs9093hvkhol0n4use4r@hive.bjoern.hoehrmann.de>

* Anne van Kesteren wrote:
>I think my proposal is that the exact semantics of the request depend on  
>RFC 2616. So if that specification states that the entity body must not be  
>included that must be honered by the XMLHttpRequest implementation (for  

You don't say how that would be accomplished (would they silently drop
the body?) and this would be both more and less than what has been re-
quested: RFC2616bis may allow GET bodies and let extensions define the
semantics of such requests, and you would require implementations to
treat HEAD requests with a body in the same way. A quick test sending
the string "body" in HEAD, OPTIONS, and EXAMPLE requests suggests:

  * IE7 and Firefox happily pass the body to the server

  * Safari/Win handles OPTIONS and EXAMPLE correctly, but
    sends a zero-length body (!) with the HEAD request

  * Opera 9.50 Beta hangs when doing the OPTIONS request,
    Opera 9.20 rewrites it to a GET request with no body

  * Opera 9.20 and Opera 9.50 Beta rewrite the EXAMPLE
    request to a GET request and do not include a body;
    both include no body with the HEAD request

I also tried sending the HTML `document` which gives similar results
except in IE7 where the browser is shut down before performing the
request. Ignoring all the insane results, we learn that HEAD bodies
pose no problem, and treating the semantically identical methods GET
and HEAD differently is clearly a bug.

It is ultimately the responsibility of the script author to ensure
the requests, to the extent the specification lets him control it,
are in accordance with the relevant HTTP specifications, and those
specifications are not set in stone: new methods that do not allow
a body may be added, existing methods may be modified, and so on.

We should not cherry pick some requirements and let implementations
silently enforce them (we do not require to drop request headers if
they are malformed, or magically add a body to requests that would
require one, for instance). I would rather suggest to add text like
this to the draft, if this is really necessary:

  Implementations are strongly discouraged from silently omitting
  entity bodies associated with GET requests, but doing so does
  not cause them to be non-compliant with this specification.

That would be exactly what Boris and Maciej were asking for.
Bjrn Hhrmann  mailto:bjoern@hoehrmann.de  http://bjoern.hoehrmann.de
Weinh. Str. 22  Telefon: +49(0)621/4309674  http://www.bjoernsworld.de
68309 Mannheim  PGP Pub. KeyID: 0xA4357E78  http://www.websitedev.de/ 
Received on Thursday, 13 December 2007 02:58:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:24 UTC