Re: [Bug 12] Destination header "consistent"

Lisa Dusseault wrote:
> Well I do agree on removing this section, and that supporting Location 
> with 207 responses isn't necessary. That means there's some text early 
> in section 12 that can go away, as well.
> 
> 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 is defined by RFC2616. Multistatus response bodies 
are defined in RFC2518. Are you saying that those definitions are 
incompatible? That would be a bug. If they aren't, there's nothing that 
needs to be fixed.

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

Do you have any evidence of interoperability problems because RFC2518 
doesn't say anything about this?

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

-1.

Please define what the problem is with what RFC2518 and RFC2616 
currently say. We can then discuss whether there's a need to fix one of 
them.

Best regards, Julian

Received on Friday, 28 October 2005 21:35:53 UTC