Re: Issue 43 (combining fragments)

Brian Smith wrote:
> Julian Reschke wrote:
>> Brian Smith wrote:
>>> MUST or SHOULD replace the fragment in original URI with the
>>> Fragment in the Location header. Keep in mind that the server
>>> doesn't even know what the original fragment was when it minted
>>> the Location header.
>> Well, if we add it, it would be a specification of client
>> behavior, not server behavior.
> 
> What I meant is: I don't see how you can define the client behavior
> Of redirects with fragments in a way that makes sense for all
> clients (not just browsers). And, even in the case of browsers, I
> don't see why Opera's behavior should be considered wrong. So,
> even if fragments are allowed syntactically, the semantics still
> will be undefined.

Well, it's up to us to decide that.

Yngwe has indicated that if we clarify the spec properly they are 
willing to follow it (I guess they'll make the change anyway, as their 
behavior differs from the "other" UAs).

> Every client that will conform to this specification sends a Host
> header to the server. And, a relative URL in a Location header
> would always be resolved relative to that Host header value.
> So, the server CAN always generate a URI; it never needs to
> generate a relative URI reference in the cases where it would
> be allowed to do so. Accordingly, in light of your demonstration
> of how poorly these two extensions work together, I think it
> makes the most sense to say something like this:
> 
> * Change the syntax to:
> 
>      Location-v = URI-reference
> 
>   This would resolve issue #185.

Yes.

> * Don't say anything about the semantics of fragments in
>   redirects. This would close issue #43 with no change.

If we don't want to mandate that we really should state that; otherwise 
confusion will continue.

> * Note in the "Changes from RFC 2616" that the syntax of
>   the Location header was changed from absolute-URI to
>   URI-reference in order to allow relative URI references
>   and fragments.
> 
> I noticed the wording of the language regarding fragments is poor:
> 
>   There are circumstances in which a fragment identifier in a
>   Location URI would not be appropriate: 
> 
>   * With a 201 Created response, because in this usage the
>     Location header specifies the URI for the entire created
>     resource.
> 
>   * With 305 Use Proxy.
> 
> This should be reworded to use RFC 2119 terminology. I suggest:
> 
>   The Location header field value MUST NOT include a fragment
>   If the response status code is 201 Created or 305 Use Proxy.
 > ...

I prefer to use RFC 2119 terminology strictly in cases where otherwise 
interoperability would suffer (see 
<http://tools.ietf.org/html/rfc2119#section-6>).

BR, Julian

Received on Thursday, 8 October 2009 13:09:19 UTC