Re: [Bug 12] Destination header "consistent"

+1 for either Jim's suggested text or saying nothing,
and +1 that we then close this issue.

Cheers,
Geoff


Jim wrote on 10/28/2005 05:38:38 PM:

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