Re: # or ? in URLS (was BOS confusion)

Eliot:
| At 11:42 PM 1/7/97 -0500, David G. Durand wrote:
| >At 4:25 PM 1/3/97, W. Eliot Kimber wrote:
| >>But wouldn't anything else be a query and thus have to go after a "?".
| >
| >   Queries _always_ invoke a server-side process. #-strings invoke a
| >client-side process, that depends on the MIME-type of the resource
| >deisgnated by the URL the #-string is attached to.
| 
| I hadn't realized that distinction.  

I believe this does not necessarily apply to URLs in general (see below).

As I understand it, the addressing of the fragment is separate from 
the semantics of the request for the object identified by the URL 
(the part before the #).  The HTTP URL defines these semantics wrt #.

From the notoriously ill-written RFC 1630 on URLs:

   HASH FOR FRAGMENT IDENTIFIERS

      The hash ("#", ASCII 23 hex) character is reserved as a delimiter
      to separate the URI of an object from a fragment identifier .

 ...

Fragment-id

   This represents a part of, fragment of, or a sub-function within, an
   object.  Its syntax and semantics are defined by the application
   responsible for the object, or the specification of the content type
   of the object.  The only definition here is of the allowed characters
   by which it may be represented in a URL.

   Specific syntaxes for representing fragments in text documents by
   line and character range, or in graphics by coordinates, or in
   structured documents using ladders, are suitable for standardization
   but not defined here.

   The fragment-id follows the URL of the whole object from which it is
   separated by a hash sign (#).  If the fragment-id is void, the hash
   sign may be omitted: A void fragment-id with or without the hash sign
   means that the URL refers to the whole object.

   While this hook is allowed for identification of fragments, the
   question of addressing of parts of objects, or of the grouping of
   objects and relationship between continued and containing objects, is
   not addressed by this document.

   Fragment identifiers do NOT address the question of objects which are
   different versions of a "living" object, nor of expressing the
   relationships between different versions and the living object.

   There is no implication that a fragment identifier refers to anything
   which can be extracted as an object in its own right.  It may, for
   example, refer to an indivisible point within an object.

 ... [from HTTP-specific portion, now obsolete but perhaps not in
      this detail:]

No fragmentid part of a WWW URI (the hash sign and
   following) is sent with the request.  Spaces and control characters
   in URLs must be escaped for transmission in HTTP, as must other
   disallowed characters.
                                  
 ... [from nonnormative examples for HTTP:]
   A reference to a particular part of a document may, including the
   fragment identifier, look like

        http://www.myu.edu/org/admin/people#andy

   in which case the string "#andy" is not sent to the server, but is
   retained by the client and used when the whole object had been
   retrieved.


Regards,
    Terry Allen    Fujitsu Software Corp.    tallen@fsc.fujitsu.com
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Received on Wednesday, 8 January 1997 19:00:25 UTC