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

Jonathan Rees wrote:
> (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.)

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?

>>> 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?
>> I have no idea what this has to do with the request-target. Could you please
>> elaborate?

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!

Received on Thursday, 11 March 2010 17:36:43 UTC