Re: [Bug 12] Destination header "consistent"

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
>>>  >
>>>  >
>>>  >
>>>  >