- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Thu, 01 Sep 2011 16:02:34 +1200
- To: <ietf-http-wg@w3.org>
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. AYJ
Received on Thursday, 1 September 2011 04:03:12 UTC