Blue Ribbon Campaign for Free Speech Footnotes for "HTTP Made Really Easy"

Home > Web Technology Made Really Easy > HTTP Made Really Easy > Footnotes


  1. Sample HTTP Client
  2. Using GET to Submit Query or Form Data
  3. URL-encoding
  4. Manually Experimenting with HTTP

Sample HTTP Client

To see a working example of an HTTP client, download and view the source code for geturl (in Perl, with comments).

geturl downloads a resource at a given URL using GET, and saves it locally if desired. The first version was written to use HTTP 1.0. It was then modified to use HTTP 1.1, taking the steps detailed on the main page in the section HTTP 1.1 Clients.

geturl runs from the command line. To download into the local file myfile, use

geturl myfile

Return to Table of Contents

Using GET to Submit Query or Form Data

You can use GET to send small amounts of data to the server. The key is to understand just what the request URI is: It's not necessarily a file name, it's a string that identifies a data resource on the server. That may be a file name, but it may also be, for example, a specific query to a specific database. The result of that query may not live in a file, but it's a data resource all the same, identified by the search engine and the query data that together produce it.

So, to send data to a CGI script using a GET request, include that data after the question mark in the URL (read about URL syntax for more details). For example,

GET /path/script.cgi?field1=value1&field2=value2 HTTP/1.0

This is an example of URL-encoded data, which is how HTML forms are submitted using the GET request. This is only appropriate if the amount of data is small, and there are no side effects on the server. Otherwise, use POST for form submission.

Return to Table of Contents


HTML form data is usually URL-encoded to package it in a GET or POST submission. In a nutshell, here's how you URL-encode the name-value pairs of the form data:

  1. Convert all "unsafe" characters in the names and values to "%xx", where "xx" is the ascii value of the character, in hex. "Unsafe" characters include =, &, %, +, non-printable characters, and any others you want to encode-- there's no danger in encoding too many characters. For simplicity, you might encode all non-alphanumeric characters.
  2. Change all spaces to plusses.
  3. String the names and values together with = and &, like
  4. This string is your message body for POST submissions, or the query string for GET submissions.
For example, if a form has a field called "name" that's set to "Lucy", and a field called "neighbors" that's set to "Fred & Ethel", the URL-encoded form data would be
with a length of 34.

Technically, the term "URL-encoding" refers only to step 1 above; it's defined in RFC 2396, section 2.4 (previously in RFC 1738, section 2.2). Commonly, the term refers to this entire process of packaging form data into one long string.

Return to Table of Contents

Manually Experimenting with HTTP

Using telnet, you can open an interactive socket to an HTTP server. This lets you manually enter a request, and see the response written to your screen. It's a great help when learning HTTP, to see exactly how a server responds to a particular request. It also helps when troubleshooting.

From a Unix prompt, open a connection to an HTTP server with something like

telnet 80

Then enter your request line by line, like

GET /path/file.html HTTP/1.0
[headers here, if any]
[blank line here]

After you finish your request with the blank line, you'll see the raw response from the server, including the status line, headers, and message body.

Return to Table of Contents

Back to Main Page

© 1997 James Marshall (comments encouraged)

Last (significantly) modified: March 18, 1997