Re: [Fwd: Request for feedback on HTTP Location header syntax + semantics, Re: Issues 43 and 185, was: Issue 43 (combining fragments)]

Toby Inkster wrote:
> I wonder if the semantics of the proposed solution to ticket 43 below have
> implications for httpRange-14?
> 
> ---------------------------- Original Message ----------------------------
> Subject: Request for feedback on HTTP Location header syntax + semantics, 
> Re: Issues 43 and 185, was: Issue 43 (combining fragments)
> From:    "Julian Reschke" <julian.reschke@gmx.de>
> Date:    Wed, March 10, 2010 1:06 pm
> To:      "HTTP Working Group" <ietf-http-wg@w3.org>
>          "public-html@w3.org" <public-html@w3.org>
> --------------------------------------------------------------------------
> 
> Hi,
> 
> the HTTPbis WG has two open tickets with respect to the syntax and
> semantics of the Location header (not to be confused with
> Content-Location!):
> 
> a) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment
> combination / precedence during redirects"
> 
> This is about how to handle the case when both the original URI and the
> value of the Location header contain a fragment identifier.
> 
> b) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location
> header payload handling"
> 
> This is about allowing relative references (in addition to full URIs),
> and also about treating broken values (*).
> 
> Some time ago I created a few tests, see
> <http://greenbytes.de/tech/tc2231/redirects.html>.
> 
> What I found was that
> 
> - UAs appear to treat those consistently (with the exception of Opera,
> but Yngwe already signaled that he's willing to adapt), *but*
> 
> - the behavior I found unfortunately doesn't make sense (treating the
> cases for absolute URIs and relative references differently).
> 
> Specifically, I would expect UAs to let the fragment ID found in the
> Location header (when present) override the original URI's. But we found
> this to be only the case for absolute URIs.
> 
> At this point, and with no further feedback from browser vendors about
> whether they'd consider changing the behavior for relative references,
> we changed the spec to clarify that the fragment recombination behavior
> is undefined (previously, the spec didn't say anything about this).
> 
> The new text for "Location" is:
> 
> -- snip --
> 9.4.  Location
> 
>     The field value consists of a single URI-reference.

If the Location header is only used to:

  1] identify a newly created resource
  2] redirect the recipient to a different location

doesn't this mean that:

  location-field-value = absolute-URI
                          / ( path-absolute [ "?" query ] )
                          / ( relative-part [ "?" query ] )

and fragments don't come in to the equation / should not be allowed?

additionally how could a secondary resource (one identified by a
uri-reference containing a fragment) be accurately redirected-to when
secondary resources are not allowed in the request-target?

Many Regards,

Nathan

Received on Wednesday, 10 March 2010 18:18:53 UTC