- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 8 Jul 2009 15:03:55 -0700
- To: Jonathan Rees <jar@creativecommons.org>
- Cc: Pat Hayes <phayes@ihmc.us>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, www-tag@w3.org
On Jul 8, 2009, at 2:30 PM, Jonathan Rees wrote: > On Wed, Jul 8, 2009 at 4:59 PM, Roy T. Fielding<fielding@gbiv.com> > wrote: >> Please, folks, stop making up things about the HTTPrange-14 issue >> which did not exist at the time it was resolved. If there are >> problems >> with the 303 definition (like "resource owner"), then they will be >> fixed in the HTTP spec. When the spec is approved, it will define >> the protocol. If people use the protocol incorrectly, that's their >> problem. The TAG decision was input to the process, not a sacred >> cow. >> >> ....Roy > > I agree completely (although it would be nice if HTTPbis took into > account the way 303 responses are currently being used by the > community you thought you would serve by adding GET/303 to HTTPbis). > In my opinion this sentence > > "A 303 response to a GET request indicates that the requested resource > does not have a representation of its own that can be transferred by > the server over HTTP." > > makes up things about the decision - namely the idea that the server > would be in possession of information about the resource's > representations or lack thereof, and would use it in deciding what > responses to send. This change is consequential to current users of > GET/303 and I just don't understand why you want to do it. That's because you happen to be reading it differently than what I was thinking when I wrote it. The sentence is a bit ambiguous if you don't pay attention to what the second "that" means. If it is reordered to say A 303 response to a GET request indicates that the server does not have a transferable representation of the requested resource and is instead redirecting the client to some other resource for further information. then I think the objection is handled without watering down the purpose of using the status code on a GET. ....Roy
Received on Wednesday, 8 July 2009 22:04:19 UTC