W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

Re: GET/HEAD support "MUST"

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 30 Jan 2009 18:56:52 +1100
Cc: Geoffrey Sneddon <foolistbar@googlemail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <4816627A-E5AA-424F-B802-62C0EC879645@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

Yes, editorial is fine unless someone feels strongly.

My assumption is that this was written when it was desirable to  
encourage servers to implement GET and HEAD, and not just POST (I  
guess). That's been achieved, so I think it's safe to remove this  
requirement.

Stating that any resource that supports GET MUST also support HEAD  
seems like a good thing, if it already hasn't been said.

Cheers,


On 30/01/2009, at 7:23 AM, Julian Reschke wrote:

>
> Geoffrey Sneddon wrote:
>> Hi,
>> Both RFC2616 and bis both include the following:
>>> The methods GET and HEAD MUST be supported by all general-purpose  
>>> servers.
>> This is unclear for several reasons:
>> a) Although the server MUST support those two methods, MUST it  
>> support it for every resource?
>
> Dunno.
>
>> b) What is a "general-purpose server"? This is the only time this  
>> phrase occurs within RFC2616, with nothing to say what it refers to.
>
> Dunno.
>
>> I mention a) because a large number of web forms create a special  
>> resource to send submissions of the form to. Inevitably, if that  
>> form is to be sent via POST, a GET request of that resource makes  
>> little sense.
>
> I guess the intent of this language is to ensure that any server  
> that implements HTTP must be prepared for GET/HEAD requests on any  
> URI.
>
> That being said, it's probably sufficient that a special resource as  
> described above just returns 401 or 501 -- so doing a retrieval  
> never ever would cause a side-effect.
>
> Mark, should we add that as editorial issue to the list?
>
> BR, Julian
>
>
>


--
Mark Nottingham     http://www.mnot.net/
Received on Friday, 30 January 2009 07:57:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:00 GMT