W3C home > Mailing lists > Public > public-webapi@w3.org > June 2006

Re: Extension HTTP methods

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 10 Jun 2006 13:57:11 +0200
Message-ID: <448AB397.8090404@gmx.de>
To: Gorm Haug Eriksen <gormer@opera.com>
CC: "Hallvord R. M. Steen" <hallvord@opera.com>, Mark Nottingham <mnot@yahoo-inc.com>, Mark Baker <distobj@acm.org>, Anne van Kesteren <annevk@opera.com>, Pete Kirkham <mach.elf@gmail.com>, "Web APIs WG (public)" <public-webapi@w3.org>

Gorm Haug Eriksen schrieb:
> On Fri, 09 Jun 2006 10:56:20 +0200, Julian Reschke 
> <julian.reschke@gmx.de> wrote:
>> So please leave this to those who actually control HTTP + extensions, 
>> which is the IETF.
> IETF should make an RFC much like <http://www.ietf.org/rfc/rfc4229.txt> 
> describing the http methods/verbs they actually control and the 
> semantically meaning and requirements for them. Without this knowledge 

I do agree that there should be a registry for HTTP methods.

> it's very hard for this group and the browser vendors to agree upon 
> behaviour. E.g. should an entity-body be passed with the verb? How 
> should the browser handle content negotiation?

Disagreement here. XHR implementations do not need any special knowledge 
about this. If a client supplies a request body, it should be sent. No 
problem here.

Regarding conneg: could you be a bit more specific? What exactly is the 
question, and how is it relevant to XHR?

> The XHR specification could point to this RFC and give some advice with 
> regards to which verbs must/may be supported. In addition to this the 
> XHR specification must describe how arbitrary verbs not in this RFC 
> should be handled (IMO they should be handled like GET's).

I don't understand this statement, because I'm not sure why XHR would 
care at all what the verb is. HTTP fully defines how message 
transmission works independently of the verb (with the single notable 
exception being the responses to HEAD).

Best regards, Julian
Received on Saturday, 10 June 2006 12:03:59 UTC

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