Re: In support of sending fragment IDs to the server (issue #43)

What's the difference between using a fragment in the URI and just using 
a querystring, or another parameter in the querystring?

If the request is going to hit the server, there are existing mechanisms 
to pass arguments.  I thought the whole point of the fragment was to 
avoid hitting the server.

Letting it go through to the server has big implications for 
intermediaries, especially caches.

So my vote is to leave it as it is.


On 4/05/2010 12:26 a.m., Bert Bos wrote:
> I see that fragment IDs of URLs are actively being discussed[1], so this
> is just my vote in favor of letting clients send fragment IDs to the
> server.
>
> One specific use case is this:
>
>      Imagine that there used to be an HTML document on some site, let's
>      call it http://example.com/all, that contained three small, related
>      topics. Over time, the document grew and also the author noticed
>      that most people referred to the fragments #one, #two and #three and
>      very rarely to the document as a whole. So he split the document
>      into three separate ones, http://example.com/{one,two,three}. That
>      is good for new links, but what to do with the old
>      http://example.com/all? You cannot replace it with a 301, because
>      there are *three* documents to redirect to.
>
> In the case of HTML, you can make a small document with three links.
> Then people have to make an extra click, but at least they will get
> there. Robots will have more trouble. And what it the document isn't
> HTML?
>
> It seems that some way to let the client give the fragment ID to the
> server is required. It could be included right in the "request-target"
> (i.e., in the partial URL that follows the GET or HEAD), or as an extra
> request header. Maybe, for backwards compatibility, it should only be
> included in the client's second request, after the server responded
> with a specific Vary header.
>
> The server could also return a translation table with the first 301 and
> let the client compute the full redirect itself. That may be enough for
> simple, enumerable fragment IDs, such as in the HTML example above, but
> it will be difficult for more complex ones, such
> as "#track=7,time=8.5", i.e., those where the (potential) number of
> fragment IDs is very large or infinite.
>
> [1] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43
>
>
>
> Bert
>
> PS. I'm not subscribed to the list. If you respond and want me to see
> the response quickly, please CC me.
>
>

Received on Monday, 3 May 2010 23:34:28 UTC