Re: Review of new HTTPbis text for 303 See Other

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