Anatomy of a URL

A URL can consist of many parts, as shown below.

protocol
:
//server
:
port
/context_path
/script_name
/path_info
?
query_string
#
fragment

The above URL parts are generally available in CFML engines via the CGI scope, and in JavaScript via the location object.

The explanations below show the CGI VARIABLE, the JavaScript variable (where available), and relevant descriptions and examples.

protocol
:

SERVER_PROTOCOL contains the name and revision of the information protcol this request came in with. Format: protocol/revision, for example "HTTP/1.1".

With JavaScript, you can use location.protocol to access the actual URL protocol (with colon included)

//server

The full domain name (or IP address) of the server. Both HTTP_HOST and SERVER_NAME generally return the same thing, but there can be differences.

With JavaScript, the variable location.host contains this information.

Although the // is technically a part of the server name it is almost always omitted outside of full URLs, and none of the above variables include it.

:
port

SERVER_PORT is the port number to which the request was sent, e.g "80", "443", "8500", etc.

With JavaScript, the variable location.port contains port number (excluding colon).

/context_path
CONTEXT_PATH

On a JEE server (e.g. Tomcat, Resin, etc) the web-context as defined in the server.xml configuration.

Most applications are defined with an empty web-context, so the context_path is the blank.

On the client-side, this will be part of location.pathname, but is not directly split out.

/script_name
SCRIPT_NAME

The (virtual) path to the script being executed, (relative to either webroot or context root as relevant).

If an incomplete path is provided (i.e. only directory), convention is to try a series of prioritised values, e.g. index.html, index.cfm, default.htm, etc)

For CFML applications, /index.cfm is the usual script name.

On the client-side, this will be part of location.pathname, but is not directly split out.

/path_info
PATH_INFO

The extra path information, as given by the client. In other words, scripts can be accessed by their virtual pathname, followed by extra information at the end of this path. The extra information is sent as PATH_INFO.

This information is not required to match a physical path, and may contain semi-colon delimited variables.

On the client-side, this will be part of location.pathname, but is not directly split out.

?
query_string
QUERY_STRING

The information which follows the ? in the URL which referenced this script is the query information. This variable is always an un-decoded string.

Standard convention is to use ampersand delimited key=value pairs to indicate variables, (though this is not required and other methods exist), and CFML engines use this convention to populate the URL scope.

From JS, the location.search variable contains the query string (with question mark included).

#
fragment

The URL fragment cannot be accessed server-side, it is a client-side-only variable, available with location.hash in JavaScript (which includes the hash itself).

It is a reference to the specific part of the document that the browser should display.

This can refer to any element id within the page, or any named anchor.

path_translated
PATH_TRANSLATED

The server provides a translated version of PATH_INFO, which takes the path and does any virtual-to-physical mapping to it.

cf_template_path
CF_TEMPLATE_PATH

The translated/expanded path (physical) for SCRIPT_NAME, available only to CFML engines.