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

From: Nathan Rixham <[email-masked]>
Date: Wed, 10 Mar 2010 18:12:02 +0000

Hi All,

> 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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 11 Mar 2010 12:11:44 +0100

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

Fragments in redirect targets are nothing new. They have been around 
since the beginning, and they are supported by UAs. And they can be useful.

> secondary resources are not allowed in the request-target?

I have no idea what this has to do with the request-target. Could you 
please elaborate?

Best regards, Julian

---

From: Jonathan Rees <[email-masked]>
Date: Thu, 11 Mar 2010 07:31:41 -0500

(bcc www-tag)

If you believe in the "identification" / "resource" / "representation"
theory then figuring this out if pretty straightforward.

Suppose http://example.com/a redirects to http://example.com/c#d, and
we want to know what resource is identified by http://example.com/a#b.
 In general resource x#y means y as locally defined in x. So
http://example.com/a#b is b as locally defined in
http://example.com/a.  To find what's in http://example.com/a, you
look at the resource http://example.com/c#d.  How a fragid is defined
locally in something depends on the media type registration, and the
only media type of which I'm aware that allows one to define locally a
fragid b to identify something that itself has representations with
the potential for fragid definition is application/rdf+xml (and the
other RDF media types). For text/html, for example,
http://example.com/c#d would identify an HTML element, and there's no
fragid namespace defined locally inside an HTML element in which #a
could be defined.

Usually, when a browser finds that a resource doesn't define the
desired fragid, it just shows you a representation of the resource. (I
vaguely remember some discussion about how the user should be alerted
when this happens, like a mild form of 404, but that's another story.)
To be consistent that is what should happen in this case. That is, it
would throw away the unresolvable #b and just show you
http://example.com/c#d. (unless the representation of
http://example.com/c is RDF that defines d to be a resource that has a
locally defined b.)

Jonathan

On Thu, Mar 11, 2010 at 6:11 AM, Julian Reschke <[email-masked]> wrote:
> Fragments in redirect targets are nothing new. They have been around since
> the beginning, and they are supported by UAs. And they can be useful.
>
> I have no idea what this has to do with the request-target. Could you please
> elaborate?
>
> Best regards, Julian
>
>

---

From: Nathan <[email-masked]>
Date: Thu, 11 Mar 2010 17:35:55 +0000

> http://example.com/c is RDF that defines d to be a resource that has a

so if we have:
  http://www.w3.org/People/Berners-Lee/card#i

and we dereference it to:
  http://www.w3.org/People/Berners-Lee/card

and we get redirected by the location to:
  http://another.org/TimBL/profile#this

which is dereferenced to:
  http://another.org/TimBL/profile

and that final request gives us an rdf representation, then are we still
looking for triples with a subject of (or something which states it is
the sameAs):
  http://www.w3.org/People/Berners-Lee/card#i

or should this redirection from Primary resource to secondary resource
"mean" something that we should be adding to the equation?

it seems that a fragment in the Location header indicates that a primary
resource is now a secondary resource, which I guess means you could add
in say five 3xx redirects like this and end up with resource that is
five levels away from being a primary resource?

>> I have no idea what this has to do with the request-target. Could you please

if a server can "redirect" from a primary resource to a secondary
resource, then this indicates that the server (or mappings) have
knowledge of both primary and secondary resources. Why then can't the
server receive requests for secondary resources in the request target so
that it can accurately map between secondary resources. for example say
that:
 http://www.advogato.org/person/timbl/foaf.rdf#me
301 Moved Permanently
Location: http://www.w3.org/People/Berners-Lee/card#i

also do fragments in the Location make sense for all 3xx codes, for
instance 303 See Other?

all in I'm a bit confused as to how to handle fragments in a Location
header when they can't be included in the request target, especially
when you chain up more than two 3xx's in a row.

Regards!

---

From: Julian Reschke <[email-masked]>
Date: Thu, 11 Mar 2010 18:45:36 +0100

> Location: http://www.w3.org/People/Berners-Lee/card#i

I can't answer that. There may have been good reasons for this when the 
web was designed. Something for people like Tim, Larry, or Roy to answer.

 From the point of view of the HTTPbis WG we're just clarifying things 
in HTTP/1.1; we don't add anything new. Fragment identifiers *are* in 
use (and so are relative references), that's why we're having this 
discussion.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 11 Mar 2010 18:55:01 +0100

> theory then figuring this out if pretty straightforward.

I think that's a theory I believe in :-).

> the potential for fragid definition is application/rdf+xml (and the

Interesting. How so? Pointer? Couldn't see that in 
<http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-fragID>.

> http://example.com/c is RDF that defines d to be a resource that has a

The good thing is that the end result for text/html is the same: the 
fragment id from the redirect URL is taken into account, the original 
fragid being overridden.

So, considering that whatever has to happen here depends on the media 
type of the representation we get from the redirect target -- isn't this 
something the spec for text/html needs to spell out?

We currently have (in "-latest"):

"Note: This specification does not define precedence rules for the case 
where the original URI, as navigated to by the user agent, and the 
Location header field value both contain fragment identifiers."

How about expanding this to something like:

"Note: This specification does not define precedence rules for the case 
where the original URI, as navigated to be the user agent, and the 
Location header field value both contain fragment identifiers. In 
particular, the semantics of fragment identifiers depend on the 
representation's media type."

...and thus make it the HTML WG's problem (for text/html)? :-)

Best regards, Julian

---

From: Jonathan Rees <[email-masked]>
Date: Fri, 12 Mar 2010 11:53:35 -0500

> <http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-fragID>.

The RDF media type registration supports the use of URIs with fragids
as "identifying" anything. You could for example say
<http://example.com/c#d> owl:sameAs <http://example.com/e>. where
http://example.com/e has an HTML representation that defines its own
local identifiers, and so on.  (The URI syntax really ought to support
scheme:path#frag#frag#frag ... so it goes...)

This is all theoretical... I'm not going to get on anyone's case for
not implementating this, only for ruling it out.

> fragment id from the redirect URL is taken into account, the original fragid
> being overridden.
>
> So, considering that whatever has to happen here depends on the media type
> of the representation we get from the redirect target -- isn't this

Only if the recovery strategy is specific to text/html (see below). If
it's generic across all media types then it's HTTP's job. I'll leave
the determination up to you.

> where the original URI, as navigated to by the user agent, and the Location
> header field value both contain fragment identifiers."
>
> where the original URI, as navigated to be the user agent, and the Location
> header field value both contain fragment identifiers. In particular, the
> semantics of fragment identifiers depend on the representation's media
> type."
>

I could live with that. Maybe remove the word "precedence" as it is
distracting. Maybe cite 3986.

The reason the spec "does not define" it (which I think is debatable)
stems from HTTP's incomplete embrace of the
identification/resource/representation theory in the case of
redirects. For example:

   "For 3xx responses, the location SHOULD
   indicate the server's preferred URI for automatic redirection to the
   resource."

More I/R/R friendly might be

   "For 3xx responses, the location SHOULD
   identify a resource for which a representation should
   be obtained."

The language for 302 and 307 talks about the resource "residing at"
another URI without defining what "residing" means (especially when
the Location: URI doesn't use the http: scheme). You could exploit the
I/R/R theory by observing that the Location: URI actually identifies
another resource (maybe the same one for a 301, I don't know) and in
the 302/307 case it's "lending" its "corresponding" representations
(and redirects) to the first resource. Then you don't have to define
"resides" and you've defined "redirect" quite clearly and abstractly.

I wouldn't mind someone arguing that in <div id="d"> foo <div id="b">
bar </div> </div> it would make sense to "go" to the div with id="b"
when http://example.com/a#b redirects to http://example.com/c#d,
although in an ideal world this would be licensed by the html (xml,
etc) media type registrations. Heck, I don't really care going to #b
when the "b" element is outside the "d" element, when what we're
talking about is classified as an error recovery case. There is some
theoretical risk that a user could be confused or tricked somehow by
this behavior, but that would be true for any error recovery behavior,
including going to the top of the document. Whether this is in the
purview of HTTP depends on whether one would want to agree on a
general recovery principle that's independent of HTML. No advice on
that matter.

> Best regards, Julian

Best
Jonathan

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Mar 2010 18:16:03 +0100

>     identify a resource for which a representation should

That would be incorrect for methods other than HEAD/GET...

But yes, clearing up the terminology about representations and resources 
is on the TODO list; hopefully we'll be able to get this done soonish.

Best regards, Julian

---

From: Nathan <[email-masked]>
Date: Fri, 12 Mar 2010 17:29:34 +0000

> general recovery principle that's independent of HTML. No advice on

Am I correct in thinking that the scope of a URI in the Location header
value has been matched to be anything that can be the target of a
hyperlink (and thus include fragments); whereas the request-target is
scoped to primary resources only as the locating of media-type specific
secondary resources can only correctly be determined by an application
which supports said media-type(s)? (preferably because the media-type
specification itself has indicated how to handle this).

And would this then indicate that the handling of conflicting fragments
between the originally requested hyperlink/uri and any subsequent
hyperlink/uri(s) would also be in the domain of each media-type's
specification (where media-type supports fragments that is).

The above would then bring me back to my original point and question
(which I didn't communicate properly) as follows:

Is HTTP adding in support for something (fragments) which is media-type
specific to an area of the specification (request/response semantics)
which is supposed to be generic across all media-types; and further
requiring adaptation/refining of specifications by media-types to cater
for http functionality; would this be acceptable if it were FTP or any
other protocol?

I'm unsure how to word this without offending or coming across wrong to
be honest - I'm aware that support for fragments in the Location header
already exists and is used; but should it have been there in the first
place?

Finally, are there any notes to say how fragments should be handled when
the media-type doesn't support them (or is this out of scope)?

Many Regards,

Nathan