Re: [Bug 12] Destination header "consistent"

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