Re: Defn of Location in 200, 301, and 302

Roy Fielding <fielding@beach.w3.org> wrote:
  > 
  > [moved from www-talk -- specification wording should be discussed here].
  > 
  > Dave Kristol wrote:
  > 
  > >I quibble with your [Marc's] interpretation of the spec.  The actual words are
  > >	"For 2xx responses, the location should be the URL needed to
  > >	retrieve the same resource again..."
  > >Apparently the "should" is ambiguous.  You read it to mean that a
  > >server *must* send a Location header, and its value "should be the
  > >URL...".  I read it to mean that *if* the server sends Location, its
  > >value "should be the URL...".
  > 
  > Yes, and that is stated clearly in the section on 200.
Which I (gulp) missed, in spite of change bars (which I appreciate) :-(.
  > 
[...]
  > >AFAIK, servers are not required to send Location except when they send
  > >a 30[123] response.  In looking at the spec., though, I find that it is
  > >fuzzy about which headers must be sent under what circumstances.  In
  > >particular, the descriptions of the 30[123] response codes should
  > >probably make explicit reference to the Location and URI headers.
  > 
  > ????? You mean, more explicit than [e.g., 302]
[...]
Oops again.  I retract my remarks about 30[123].  (Sherlock Holmes would
have said to me, "You look, but you do not observe.")

  > >In general it would be nice to be able to identify quickly which
  > >headers are required and which, optional.  (That's a weasily way of
  > >saying "Would someone else please propose such content for the spec.")
  > 
  > I tried several such mechanisms, none of which worked.  The spec cannot
  > be simpler than the protocol and still remain correct.

Yeah, the reason I wimped out was that I couldn't think of any either.
The problem from an implementor's standpoint (mine) is, how do I know
what stuff I must send or accept, and when?  Yes, careful reading of
the spec. should do it.  But it would be nice if the spec. helped a bit.
(Not meant as a criticism of the editor.)

Dave

Received on Wednesday, 9 August 1995 14:39:55 UTC