W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: #310, was: #160: Redirects and non-GET methods

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 01 Sep 2011 16:02:34 +1200
To: <ietf-http-wg@w3.org>
Message-ID: <484574f596cfd2e2a3840635ce9a29be@treenet.co.nz>
 On Thu, 1 Sep 2011 11:33:47 +1000, Mark Nottingham wrote:
> On 01/09/2011, at 11:31 AM, Roy T. Fielding wrote:
>> On Aug 31, 2011, at 5:21 PM, Mark Nottingham wrote:
>>> Is this going to confuse new readers?
>> New readers don't know what retrieval means?
> Considering all of the issues we've had with other redirects and
> methods, I'm wary of making it more abstract...
>>> Can we clarify with something like
>>> """
>>> ...perform a retrieval request (i.e., a GET, unless the original 
>>> method was HEAD)...
>>> """
>> The problem is that the redirect might be to any URI,
>> and thus the next request might not be HTTP.
> Ah. How about
> "... perform a retrieval request (in HTTP, a GET, unless the original
> method was HEAD)..."

 I know part 1 section 2.1 only mentions GET when mentioning retrieval 
 methods. But my reading of part 2 section 7 definitions from *-16 
 clearly implies GET, HEAD and OPTIONS are all retrieval methods for 
 different things.

 So... I think that can just as easily be stated:

   perform a retrieval request (i.e. GET or HEAD)

 The case which may seem odd is when doing a HEAD and following with a 
 GET, but then there should have either been no changes by the system, or 
 any changes done did not require a body in the original request. ie all 
 those forms using GET method to post URL parameters could as easily use 
 HEAD and save on reply bandwidth, inline with the definition of HEAD 
 being identical to GET without a reply body.

Received on Thursday, 1 September 2011 04:03:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC