- From: Ed Davies <edavies@nildram.co.uk>
- Date: Wed, 12 Sep 2007 11:55:36 +0100
- To: 'Technical Architecture Group WG' <www-tag@w3.org>
Rhys Lewis wrote: > ... > My interpretation is that when you get a 303 you don't get a response to > the request you made. Otherwise, there would be no point in redirecting. I > perhaps stated this a little strongly, but I believe that what I wrote is > in the spirit of the intent of 303. > ... This paragraph points up an important distinction which I think has been part of the problem with the discussion of 303s. They can be looked at in two different ways: 1. Small speed bumps on the way to a 200 response, which set a flag that the eventual response is somehow not quite really a representation of the resource you originally asked for, or 2. Pretty much the same as a 404, but with a consolation prize in the form of a hint as to where to go to look for more information. It seems to me that a lot of the discussion has been people coming from these two viewpoints talking past each other. The actual protocol on the wire is the same in each of case, it's how you think about what's happened that's different. Hence, the specs, RFC 2616 in particular, are not so helpful. I'm in the second group - but only because it seems like the right design to me, not because the 2007-05-31/ HttpRange-14 draft or RFC 2616 makes it the only reasonable interpretation. In fact, the wording of RFC 2616 seems to lean more towards the first viewpoint but, perhaps, only because it was originally written with the response to a POST in mind which is not applicable here. Ed.
Received on Wednesday, 12 September 2007 10:56:04 UTC