Re: [Bug 12] Destination header "consistent"

The original question that brought up this issue was how to interpret 
the URLs inside the body of the Multi-Status if there was a Location 
header.  It was unclear to some client implementors
  - should the URLs in the body be relative to the Location header
  - should they be relative to the Request-URI
  - should they be absolute URLs, always, and if so, should they be 
consistent with the Location header or the Request-URI

There was an actual interoperability problem that uncovered this.  Some 
server returned a Location header and a bunch of URLs in the body, that 
used the new location.  The client errored because the client never 
expected to query a Collection for its children and find a bunch of 
URLs that didn't begin with the URL used in the request URI.

Lisa

On Oct 31, 2005, at 10:53 AM, Cullen Jennings wrote:

>
>  Thanks - Well if that's the case, seem like an argument that 
> everything that needs saying has already been said.
>
>
>  On 10/31/05 4:16 AM, "Geoffrey M Clemm" <geoffrey.clemm@us.ibm.com> 
> wrote:
>
>>
>> You would do the same as what you would always do with a Location
>> header in a response, i.e., use the URL specified in the Location 
>> header
>> the next time you wanted to apply a method to the resource.
>>
>> Cheers,
>> Geoff
>>
>> Cullen Jennings <fluffy@cisco.com> wrote on 10/30/2005 02:53:15 PM:
>>
>>  > On 10/28/05 8:24 PM, "Geoffrey M Clemm" 
>> <geoffrey.clemm@us.ibm.com> wrote:
>>  >
>>  > >
>>  > > +1 for either Jim's suggested text or saying nothing,
>>  > > and +1 that we then close this issue.
>>  > >
>>  > > Cheers,
>>  > > Geoff
>>  >
>>  > So I am a client implementer, should I do anything with the 
>> Location header
>>  > in a 207 or should I just always ignore it?
>>  >
>>
>
>