The HTTP protocol specifies that the path is handled transparently by those who handle URLs, except for the servers which de-reference them. The path is passed by the client to the server with any request, but is not otherwise understood by the client.
The host details are not passed on to the client when the URL is an HTTP URL which refers to the server in question. In this case the string sent starts with the slash which follows the host details. However, when an HTTP server is being used as a gateway (or "proxy") then the entire URI, whether HTTP or some other scheme, is passed on the HTTP command line. The search part, if present, is sent as part of the HTTP command, and may in this respect be treated as part of the path. 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.
These examples are not part of the specification: they are provided as illustations only. The URI of the "welcome" page to a server is conventionally
As the rest of the URL (after the hostname an port) is opaque to the client, it shows great variety but the following are all fairly typical.
http://www.my.uni.edu/info/matriculation/enroling.html http://info.my.org/AboutUs/Phonebook http://www.library.my.town.va.us/Catalogue/76523471236%2Fwen44--4.98 http://www.my.org/462F4F2D4241522A314159265358979323846
A URL for a server on a different port to 80 looks like
A reference to a particular part of a document may, including the fragment identifier, look like
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.
A search on a text database might look like
and on another database
In all cases the client passes the path string to the server uninterpreted, and for the client to deduce anything from