W3C home > Mailing lists > Public > www-tag@w3.org > July 2009

Re: Review of new HTTPbis text for 303 See Other

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 8 Jul 2009 15:03:55 -0700
Message-Id: <A4780937-AF79-43BA-BCEA-9F9606E27197@gbiv.com>
Cc: Pat Hayes <phayes@ihmc.us>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, www-tag@w3.org
To: Jonathan Rees <jar@creativecommons.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.

Received on Wednesday, 8 July 2009 22:04:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:30 UTC