Clinton Wong - HTTP Pocket Reference: Hypertext Transfer Protocol

Starting PageTable of ContentFront MatterChapter 1. HTTP Pocket Reference1.1 What Is HTTP?1.2 HTTP Transactions1.3 Client Methods1.4 Server Response Codes1.5 Headers1.6 URL Encoding1.7 Client and Server Identification1.8 Referring Documents1.9 Retrieving Content1.10 Media Types1.11 Cookies1.12 Authorization1.13 Persistent Connections1.14 Client Caching

This book describes HTTP, the Hypertext Transfer Protocol. Itprovides a high level description of how the protocol works, alongwith reference information on client requests and server responses.Included are dumps of HTTP transactions, as well as tabular data thatsummarizes most of the standardized parameters used in HTTP.

The HTTP Pocket Reference is intended for system administrators, website developers, and software engineers. With an understanding ofHTTP, system administrators will have a better understanding of website configuration and debugging. Web site designers can implementservices that make better use of the protocol and streamline webclient and server interaction. Software engineers who need toimplement HTTP will find this book useful for its short, concisedescription of the protocol.

HTTP Pocket Reference

Copyright 2000 O'Reilly & Associates, Inc. All rights reserved.

Printed in the United States of America.

Published by O'Reilly & Associates, Inc., 101 Morris Street,Sebastopol, CA 95472.

The O'Reilly logo is a registered trademark of O'Reilly &Associates, Inc. Many of the designations used by manufacturers andsellers to distinguish their products are claimed as trademarks.Where those designations appear in this book, and O'Reilly &Associates, Inc. was aware of a trademark claim, the designations havebeen printed in caps or initial caps. The use of the ground squirrelimage in association with HTTP is a trademark of O'Reilly &Associates, Inc.

While every precaution has been taken in the preparation of thisbook, the publisher assumes no responsibility for errors or omissions,or for damages resulting from the use of the information containedherein.

The Referer header indicates which document referred to the one currentlyspecified in this request. This helps the server keep track ofdocuments that refer to malformed or missing locations on the server.

For example, if the client opens a connection towww.ora.com at port 80 and sends:

GET /contact.html HTTP/1.1Host: www.ora.com

The server may respond with:

HTTP/1.1 200 OKDate: Tue, 04 Apr 2000 02:22:47 GMTLast-Modified: Sat, 18 Mar 2000 17:18:22 GMTETag: "134e8-b2a-38d3ba5e"Accept-Ranges: bytesContent-Length: 2858Connection: closeContent-type: text/html Sales Department

The user clicks on the hyperlink and the client requestssales.html fromsales.ora.com, specifying that it was sent therefrom the /contact.html document onwww.ora.com:

GET /sales.html HTTP/1.1Host: sales.ora.comReferer: http://www.ora.com/contact.html

The Content-length headerspecifies the length of the data (in bytes) that is returned by theserver. Due to the dynamic nature of some requests, the Content-length is sometimes unknown, and thisheader might be omitted.

There are three common ways that a client can retrieve data from theentity-body of the server's response:

• The first method involves retrieving the size of the document fromthe Content-length header, and then reading inthat much data from the network connection. Using this method, theclient knows the size of the document before retrieving it.

• In other cases, when the size of the document is too dynamic for aserver to predict, the Content-length header isomitted. When this happens, the client reads in the data portion ofthe server's response until the server disconnects the networkconnection. This practice is obsolete and only works in HTTP 1.0. Forgenerating data without knowing the total message length in advance,the next method is recommended.

• Another header could indicate when an entity-body ends, like HTTP1.1's Transfer-Encoding header with the chunked parameter.

In HTTP 1.1, the client does not have to retrieve the entireentity-body at once, but can get it in pieces, if the server allowsit to do so. If the server declares that it supports byte rangesusing the Accept-Ranges header:

HTTP/1.1 200 OK[Other headers here]Accept-Ranges: bytes

The client can then request the data in pieces. For example:

GET /largefile.html HTTP/1.1[Other headers here]Range: 0-65535

When the server returns the specified range, it includes a Content-range headerto indicate which portion of the document is being sent, and also totell the client how long the file is:

HTTP/1.1 200 OK[Other headers here]Content-range: 0-65535/83028576

For caching purposes, a client can use the If-Range header alongwith Range to request an updated portion of thedocument only if the document has been changed. Here is an example:

GET /largefile.html HTTP/1.1[Other headers here]If-Range: Mon, 02 May 1996 04:51:00 GMTRange: 0-65535

The If-Range header can use either a last modifieddate or an entity tag to verify that the document is still the same.

One of the most important functions of headersis to make it possible for the recipient of the data to know whatkind of data it is receiving, and thus be able to process itappropriately. If the client didn't know that the data returnedby the server was a GIF image, it wouldn't know how to renderit on the screen. If it didn't know that some other data was anaudio snippet, it wouldn't know to call up an external helperapplication. For negotiating different data types, HTTP incorporatedInternet Media Types, which look a lot like MIME types but are notexactly MIME types.

The client tells the server which media types it can handle, usingthe Accept header. The server tries to returninformation in one of the client's preferred media types, anddeclares the type of the data using the Content-type header.

The Accept header is used to specify theclient's preference for media formats, or to tell the serverthat it can accept unusual document types. If this header is omitted,the server assumes that the client can accept any media type. The Accept header can have three general forms:

Accept: */*Accept: type /*Accept: type/subtype

Using the first form, */* , indicates that theclient can accept an entity-body of any media type. The second form, type/* , communicates that an entity-bodyof a certain general class is acceptable. A client may issue an Accept: image/* to accept images, where the typeof image (GIF, JPEG, or whatever) is not important. The third formindicates that an entity-body from a certain type and subtype isacceptable. For example, a browser that can only accept GIF files mayuse Accept: image/gif .

Copyright Table of Contents Full Description About the Author Colophon Reader reviews Errata

HTTP Pocket Reference ClintonWong Publisher: O'Reilly First Edition May 2000 ISBN: 1-56592-862-8, 80 pages All web programmers, administrators, and application developers need to be familiar with HTTP in order to work effectively. The HTTP Pocket Reference provides a solid conceptual foundation of HTTP, and also serves as a quick reference to each of the headers and status codes that compose an HTTP transaction. For those who need to get "beyond the browser," this book is the place to start.

Next page