- From: Pat Hayes <phayes@ihmc.us>
- Date: Thu, 9 Jul 2009 11:04:00 -0500
- To: Jonathan Rees <jar@creativecommons.org>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, www-tag@w3.org
On Jul 9, 2009, at 5:03 AM, Jonathan Rees wrote: > On Wed, Jul 8, 2009 at 6:03 PM, Roy T. Fielding<fielding@gbiv.com> > wrote: > >> 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 > > Excellent! The rewording you give above would be fine with me - I > would be satisfied if HTTPbis said this, or something equivalent. > (because then the choice to yield a 303 can be attributed to the > server, and would not necessarily reflect on the nature of the > resource - "the server does not have" vs. "the resource does not > have".) Hmm, then I am puzzled. Does 303 redirection really imply that the server **does not have** a transferable representation? Surely 303 redirection is used under other circumstances than this, circumstances which have nothing whatever to do with http-range-14 and were being used before the http-range-14 issue was even raised? No? Pat > > Best > Jonathan > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Thursday, 9 July 2009 16:04:53 UTC