Loading ...
Sorry, an error occurred while loading the content.

9678Re: [rest-discuss] 30x Status codes

Expand Messages
  • Roy T. Fielding
    Oct 2, 2007
    • 0 Attachment
      On Oct 2, 2007, at 3:28 PM, Mark Baker wrote:
      > On 10/2/07, Nick Gall <nick.gall@...> wrote:
      > > On 10/2/07, Mark Baker <distobj@...> wrote:
      > > > On 10/2/07, Nick Gall <nick.gall@...> wrote:
      > > > > Wouldn't using the Content-Location HTTP header field also be
      > a "good way to canonicalize your resources"?
      > > >
      > > > In theory, yes. In practice in the wild, not so much.
      > >
      > > Agreed. But I was thinking about "Web API" (programmatic) use of
      > HTTP
      > > as opposed to typical browser behavior. As long as one documented
      > > one's interface and clients used HTTP libraries with full access to
      > > headers, then using Content-Location should be straightforward.
      > Unless
      > > intermediaries (eg caches) typically strip such headers in
      > flight. Do
      > > they?
      > I believe that's what Roy said, yes.

      I meant to say that origin servers sometimes don't know
      what their own real URI should be due to the presence of
      intermediaries that rewrite incoming requests. And, because
      those same intermediaries aren't smart enough to rewrite
      responses that contain C-Location values (or simply don't know
      if the origin server already did that for them), the resulting
      field value is often wrong.

      That could be solvable using relative values for the
      location and a better description in the spec. I am not
      convinced that the 209 code is needed. OTOH, I also heard
      second-hand complaints from browser implementers that IIS is
      sending bogus location values by default.

    • Show all 15 messages in this topic