Re: [Bug 12] Destination header "consistent"

One thing I noticed when checking this against and editing the text  
(sometimes this turns up new observations):   We actually use the  
Location header in response to a MOVE request, in section 8.9.5 of  
RFC2518.   Yet there's no explanation for this -- the text around the  
example doesn't indicate whether the server could have chosen a  
different destination URL (which seems very harmful to interoperability  
to me) or, if not, why the Location header is even needed.

8.9.5 Example - MOVE of a Non-Collection

     This example shows resource
     http://www.ics.uci.edu/~fielding/index.html being moved to the  
location http://www.ics.uci.edu/users/f/fielding/index.html. The  
contents of the destination resource would have been overwritten if the  
destination resource had been non-null. In this case, since there was  
nothing at the destination resource, the response code is 201  
(Created).

     >>Request

     MOVE /~fielding/index.html HTTP/1.1
     Host: www.ics.uci.edu
     Destination: http://www.ics.uci.edu/users/f/fielding/index.html

     >>Response

     HTTP/1.1 201 Created
     Location: http://www.ics.uci.edu/users/f/fielding/index.html

----

What if I remove the header from the response example, in addition to  
Jim's suggested change?

Lisa


On Oct 28, 2005, at 2:49 PM, Lisa Dusseault wrote:

> That's pretty concise and still useful.  I can live with that.
>
> Lisa
>
> On Oct 28, 2005, at 2:38 PM, Jim Whitehead wrote:
>
>>>
>> Lisa writes:
>>
>>> However, without those pieces of text, the use of the Location  
>>> header with 207 responses becomes undefined, and that always makes  
>>> me feel uncomfortable. Server implementors won't know for sure if  
>>> they can use the Location header, it seems logical that it might  
>>> work but as we've seen there are some subtleties in how the client  
>>> might interpret that. Clients are probably not prepared to handle  
>>> it. So I propose that we include text to be clear that the Location  
>>> header SHOULD NOT appear in certain responses.
>> The HTTP specification generally doesn't explain all interactions of  
>> methods, headers, and response codes. Location only has defined  
>> semantics for certain response codes in HTTP.
>>
>> On the other hand, the HTTP spec. isn't necessarily such a paragon of  
>> good writing that we should strive to emulate it.
>>
>> My solution to this issue is to add the text:
>>
>> "Use of the Location header with the methods and response codes  
>> defined in this specification is intentionally undefined."
>>
>> And leave it at that. This lets clients know they can't depend on the  
>> feature, and lets servers know they probably shouldn't go there. But,  
>> if a later spec. does add something here (like a refined REDIRECT  
>> spec.), then the door is left open for new behavior.
>>
>> Can we please close this issue?
>>
>> - Jim
>>
>>>
>>> I'm sensitive to the worry of preventing extensions but surely  
>>> there's some way of dealing with that. An extension can override  
>>> "SHOULD" level requirements, or we could come up with some  
>>> "exception" language... as in "servers SHOULD NOT return a Location  
>>> header in these responses unless the client has some way to  
>>> interpret that header."
>>>
>>> Lisa
>>>
>>> On Oct 27, 2005, at 8:17 PM, Geoffrey M Clemm wrote:
>>>
>>>
>>>>
>>>> +1
>>>>
>>>> w3c-dist-auth-request@w3.org wrote on 10/27/2005 07:50:06 PM:
>>>>
>>>>  >
>>>>  > >
>>>>  >
>>>>  > Julian writes:
>>>>  > > Back to this issue:
>>>>  > >
>>>>  > > 1) I'm not aware of any interop problems.
>>>>  > >
>>>>  > > 2) I'm not aware of anybody having asked about this.
>>>>  > >
>>>>  > > 3) I don't see any benefit in RFC2518bis making statements  
>>>> about
>>>>  > > this, even if we *did* agree on what to say
>>>>  >
>>>>  > I have just read through this entire thread, and I agree with his
>>>>  > statement above, and the conclusion Julian reached in:
>>>>  >  
>>>> http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/ 
>>>> 0294.html
>>>>  >
>>>>  > Specifically:
>>>>  >
>>>>  > * I don't think there is a compelling need to disallow Location  
>>>> and 207
>>>>  > * I don't think we need any special mechanism for handling 3xx  
>>>> within
>>>>  > a PROPFIND
>>>>  > * I think it's fine if a client needs to retry a PROPFIND  
>>>> request if
>>>>  > it receives a 3xx response
>>>>  >
>>>>  > I feel a slight desire to add a 3xx response to one of the  
>>>> PROPFIND
>>>>  > 207 response examples in the text, but could live without it.
>>>>  >
>>>>  > Unless others chime in, I think we're seeing rough consensus for
>>>>  > removing the current 8.1.3, whose text is described in Bug 12  
>>>> within
>>>>  > Bugzilla:
>>>>  > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12
>>>>  >
>>>>  > - Jim
>>>>  >
>>>>  >
>>>>  >
>>>>  >