Alexander Johannesen wrote:
>
> If the content-type is something more like XML, the anchor - being at
> the mercy of the server - is a different resource all-together. The
> only reason HTML content-types returns the *same* as with an anchor is
> because we have decided that special case for HTML and browsers.
>
Huh, I don't think this is true. I thought it was part of HTTP in
general, regardless of content-type, that the user-agent will never send
the "fragment identifier" (aka the "hash part") to the server. So the
disposition of a request can't possibly be determiend by the server
based on the fragment identifier, whether it's text/html or
application/xml or anything else. It's not a special case for HTML, it's
general for anything HTTP.
Am I wrong? There's so many overlapping specs involved that I'm not
sure where to look to answer this question, but I'd note that the HTTP
1.1 spec (RFC 2616) doesn't mention the "hash part"/"fragment
identifier" at all, and that spec in fact defines http URLs as: <<
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
>>. Note that there is no "hash part"/"fragment identifier" included
in that pseudo-BNF. I really don't think the fragment identifier will
EVER be sent to the server, it's not a special case for HTML.
But yes, as Alexander says, this certainly HAS caused a lot of confusion. :)
I have to admit I'm kind of a "linked data heretic". The "httpRange-14"
thing has never won me over, it seems more confusing than it's worth,
and I really don't like pinning all this meaning on the use of fragment
identifiers, which seems inherently confusing to me.
Received on Thu Nov 12 2009 - 10:14:33 EST