Re: How can one use '#' in a URL?

eostrom@fiicmds04.tu-graz.ac.at (Erik Ostrom)
From: eostrom@fiicmds04.tu-graz.ac.at (Erik Ostrom)
Message-id: <9306181458.AA10525@iicm.tu-graz.ac.at>
Date: Fri, 18 Jun 93 16:58:36 +0200
To: wmperry@mango.ucs.indiana.edu
Cc: p.lister@cranfield.ac.uk, www-talk@nxoc01.cern.ch
In-reply-to: <9306181430.AA24713@dxmint.cern.ch> (wmperry@mango.ucs.indiana.edu)
Subject: Re: How can one use '#' in a URL?

   >http://www/foo/bar.tar.Z#blech.c
   >
   > - this would indicate to the server that it is to unpack blech.c from
   >/foo/bar.tar.Z and send it back as a normal file. However, I have only
   >seen the # documented as something which browsers can use for internal
   >hyperlinks, not as part of the a URL that can be sent to a http server.
   >Is this a problem?

      I don't think this is correct.  Any url can make use of the # directive.
   It just tells a browser to go to a specific part of a document instead of
   to the beginning.  I don't know of any browsers that actually 'generate'
   these internally.

But I think Peter is correct that, given a URL with a # inside it, the browser
doesn't send back the part beginning with #.  That is, seeing the URL above, a
browser would ask www for a document /foo/bar.tar.Z and then look for the
anchor "blech.c" inside it--which is not what he wants.

      The only problem with using ./ in the path would be that the browser
   is likely to interpret it as a relative pathname.  For example,
   http://www/foo/bar.tar.Z#./blech.c would more than likely be translated
   into http://www/foo/bar.tar.Z#/foo/blech.c by a browser.

      It would be fairly easy to tell the replacing function not to replace
   any . or .. after a # sign though.  (I haven't tried this with mosaic or
   lynx yet, but I know that my emacs browser would replace the ./ with nothing
   so the url above would be http://www/foo/bar.tar.Z#blech.c)

As mentioned above, I don't think the browser should interpret the part after
# as part of a path, since the # character is supposed to be followed by an
anchorid and anchorids are not hierarchical.  Wanted to note, though, that
according to the URL spec "/." may be simplified but "./" is not.

Of course, according to the URL spec gopher addresses have a slash between
gtype and selector, too, and that doesn't seem to have affected implementation
any.

   -Bill Perry

-Erik