Comment 15 for bug 302656

Here's an idea:

1. Canonical URLs will not use fragment syntax (will not contain a hash mark). The embed/share functionality only generates canonical URLs.

2. User agents visiting a canonical URL that maps to a non-JS reader will read consecutive pages by loading a new page, so the reader url will be updated correctly in this case.
e.g. after retrieving http://www.archive.org/stream/alice/page/23 it will retrieve http://www.archive.org/stream/alice/page/24

3. User agents visiting a canonical URL that maps to a JS client side reader will be redirected to a URL where the trailing portion of the URL containing reader options is replaced with a hash fragment. We use a redirect to avoid multiple page loads.
e.g. the browser requests http://www.archive.org/stream/alice/page/23 is redirected to http://www.archive.org/alice#page/23

The browser client side will dynamically update the browser location using location.replace. This allows bookmarking and if the window URL is copied and pasted the correct page will load.

If the embed/share functionality is invoked a canonical URL is generated. This is more future proof and looks better in citations.

The problem with this scheme is if we redirect someone to http://www.archive.org/alice#page/23 since that will be served with a JS client-side reader and they *don't* have JavaScript we lose everything after the hash mark. Not sure how big a problem this is.