|
 |
The TCP/IP Guide
9 TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)
9 TCP/IP Key Applications and Application Protocols
9 TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)
9 TCP/IP World Wide Web (WWW, "The Web") and the Hypertext Transfer Protocol (HTTP)
9 TCP/IP Hypertext Transfer Protocol (HTTP)
9 HTTP Entities, Transfers, Coding Methods and Content Management
|
HTTP Data Transfer, Content Encodings and Transfer Encodings
(Page 3 of 3)
Use of Content and Transfer Encodings in HTTP
Since the two encodings are applied
at different levels, it is possible for both to be used at the same
time. A content encoding may be applied to an entity and then placed
into a message. On some or all of the hops that are used to move the
message containing that entity, a transfer encoding may be applied to
the entire message (of course including the entity). The transfer encoding
is removed first, and then the content encoding.
Okay, so what are these used for
in practice? Not a great deal. The HTTP standard defines a small number
of content and transfer encodings, and specifies that additional methods
may be registered with the IANA.
As of the time that I write this, however, only the ones defined in
the HTTP/1.1 standard are in use.
Content encodings are currently used
only to implement compression. This is a good example of an encoding
that while not strictly necessary, can be useful since it improves performance—for
some types of data, dramatically. The RFC 2616 defines three different
encoding algorithms: gzip (the compression used by the UNIX gzip
program, and described in RFC 1952); compress (again, representing
the compression method used by the UNIX program of that name) and deflate
(a method defined in RFCs 1950 and 1951).
 Note: It is also possible to apply compression to an entire HTTP message as a transfer encoding. Obviously, if the entity is already compressed using content encoding, this will result in some duplication of effort. Since the size of HTTP headers is not that large compared to some entities that HTTP messages carry, it is usually simpler just to compress the entity using content encoding.
|
Since transfer encodings are intended
to be used to make data safe for transfer, and we’ve already discussed
the fact that HTTP can handle arbitrary binary data, this suggests that
transfer encodings are not really necessary. As it turns out, however,
there is one situation where “safe transport” does become
an issue: the matter of identifying the end of a message. This issue
is the subject of the
next topic.
 Key Concept: HTTP supports two levels of codings for data transfer. The first is content encoding, which is utilized in certain circumstances to transform the entity carried in an HTTP message; the second is transfer encoding, which is used to encode an entire HTTP message to assure its safe transport. Content encodings are often employed when entities are compressed to improve communication efficiency; transfer encoding is used primarily to deal with the problem of identifying the end of a message.
|
| If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support! |
|
|
Home -
Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.
|
