A Uniform Resource Locator (URL) provides a "method for finding"
something. As an example, if you accessed the Internet directly, then
http://www.myerskids.com/ would be a URL as well as a URI (uniform
resource identifier). If you accessed the Internet through a proxy,
then the URI would be
http://www.myerskids.com/, but perhaps the URL
http://mwires.com:8080/proxy/www.myerskids.com/. It's rarely
necessary to distinguish between URI and URL, but URL has become
ubiquitous. However, in some technical writing, URI is preferred.
The most powerful part of a URL for a Web developer is its query string. The query string contains data values and parameters from a form or other programs which submit data to your Web site.
It's important for all Web developers to have access to the query string data contained in a URL. This is especially true for developers who can't afford to pay for their own Web sites. The content at a free Web site is NOT necessarily inferior to the content at a registered domain name. Sometimes it's the other way around. Many people enjoy free Web hosts like Angelfire, as evidenced by Angelfire's ranking of 620 out of billions of Web sites.
Format of the query string
An HTTP URL is defined in RFC 2616 (HTTP/1.1) by:
Perhaps you've noticed that long and garbled looking URLs look normal at first, and have wondered whether someone went crazy after the question mark. Before the question mark is simply the Web host and the complete path name of the file being accessed, relative to the server or virtual host document root. After the question mark is the data being communicated, called the "query" or the "query string."
The query string is usually logged in the server log files*, but unless a program is there to handle the query, and understands what was in it, nothing much will happen. You can even submit data of your own. Thankfully, so far as I know, it isn't yet illegal to submit random data for the purposes of experimentation.
(Using static files rather than CGI scripts and recording the data in a log file for future processing is efficient bulk data processing for high traffic Web sites. You can imagine, "Your request will be processed within the next five minutes." Running one program to process 500 little lines of a log file every five minutes is an idea that I've taken advantage of to improve the performance of a Web server struggling to launch several new CGI scripts every second.)
A basic query string looks like this: