In just under two decades, the URI, or more specifically the HTTP URL, has risen from a humble remote file identifier on an experimental system to a key component of modern business. The URI can be seen on billboards, television commercials, business cards and even t-shirts. The URI has every bit, if not more of the potency of the telephone number, fax number and e-mail address that came before it.

The HTTP URL is a very significant part of the user interface of any Web site indeed. URLs are scrawled by hand, recited over the telephone, typed into Web browsers from printed material, or even optically scanned. It is therefore essential that they be as clear and unambiguous as possible.

The specification that defines the syntax for all URIs does so in a fairly broad manner in order to accomodate a multitude of schemes and therefore promote adoption and keep the spec future-proof. Since HTTP URLs form a proper subset of generic URIs, the generous constraints on their syntax are carried forward with little to no modification.

Despite being an eminently flexible protocol, HTTP was designed with a specific type of interaction in mind. The generic URI syntax allows constructs that imply meanings that are either inconsistent with the goals of the protocol, or that are just plain hard to use. Therefore, in the interest of conceptual integrity, it makes sense to further constrain the syntax of HTTP URLs to promote interaction that is both efficient and effective.

This section proposes additional constraints in the following areas:

• Domain Name Recommendations
• Hyphen vs. Underscore
• Other Non-Alpha-Numeric Characters in HTTP URLs
• HTTP URL Path Syntax Constraints
• HTTP URL Query String Syntax Constraints