GridLab
Grid Application Toolkit

A simple API for Grid Applications 		GAT
Menu


next up previous contents
Next: Server Response Up: HTTP Previous: Establishing a Connection   Contents

Client Request

After the formalities of introduction have taken place, it falls to the client-suitor to utter the first words to his suited-server. Just as modern day ``Romeos'' have some pretty standard pick-up lines, so to the first words spoken to the suited-server 99.99999...percent of the time fall into one of the following categories:
  • GET - The client wants some information from the server corresponding to the queried URI. (In the modern language of love this would read: ``Yo', you lookin' kin'a sweet da girliy; whys don't you slip me all da digits in your little black book?'')
  • HEAD - The client wants information about the information he would have gotten had he done a GET. (In human terms, ``If I were to ask you for all the phone numbers in your little black book, how many phone numbers would I get?'')
  • POST - The client wants to give the server some information to be added to the information corresponding to the URI queried. (``Here's my phone number, add it to you little black book.'')
  • PUT - The client wants to give the server information to replace the information corresponding to the URI queried. ( In practical terms, ``Here's my phone number, it's the only one you'll need in your little black book.'')
  • DELETE - The client wants the server to erase the information corresponding to the URI queried. ( ``Erase that little black book of yours; I'm the one for you.)
In practice the vast majority of the client-suitor requests are of the GET type. (The clients are typical males, always wanting something and never willing to give.) For example, if the queried URI is of the form

http://www.sleestaks.com/index.html

and if the client sent a GET query to the server corresponding to this URI, then the client would, according to the rules of HTTP courtship, send to the server text with the following form:

GET /index.html HTTP/1.1

The first text ``GET'' indicates that request is using the ``GET'' method. The second text ``/index.html'' is a relative URI to the requested resource on the server. The final text ``HTTP/1.1'' indicates the version of the HTTP protocol that the client understands. In addition, there are various other bells-and whistles one can add to this simplest of GET statements.

Generically these bells-and-whistles take the form of key/value paris that a client can add to such a request. They are generically of the form

Key: Value

This is where things start to get fun. The client-suitor can specify exactly the kind of suited-server he can deal with. So, just like a personal add, Smoker=No MinimumAge=21 MaximumAge=126,..., the client can specify exactly what he desires in this mate. For example, if the client can only accept HTML text, he could specify such through such the key/value pair,

Accept: text/html

Or, for example, if the client can accept HTML text, plain text, and GIF images, then he could specify such


Accept: text/html
Accept: text/plain
Accept: image/gif

In addition to the ``Accept'' key there are about 20 other key's which are part of the HTTP/1.1 standard[*].

Finally, the rules of the court dictate that this lover's first missive is terminated by a blank line, two carriage return linefeed pairs \r\n\r\n. So, a realistic GET request from a client would look something like the following


GET /index.html HTTP/1.1
Accept: text/html
Accept: text/plain
Accept: image/gif

Even though you can't see it, there is a blank line terminating this love missive; I swear! (The disbelievers among you may let the measuring tape decide.)

next up previous contents
Next: Server Response Up: HTTP Previous: Establishing a Connection   Contents
Andre Merzky 2004-05-13