- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 10 Jun 2006 13:57:11 +0200
- 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