Please Whitelist This Site?

I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)

If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.

If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.

Thanks for your understanding!

Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide


NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The Book is Here... and Now On Sale!

The whole site in one document for easy reference!
The TCP/IP Guide

Custom Search







Table Of Contents  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

Previous Topic/Section
HTTP Entities and Internet Media Types
Previous Page
Pages in Current Topic/Section
1
23
Next Page
HTTP Data Length Issues, "Chunked" Transfers and Message Trailers
Next Topic/Section

HTTP Data Transfer, Content Encodings and Transfer Encodings
(Page 1 of 3)

In the previous topic, I mentioned two specific issues that HTTP had to address in order to carry a wide variety of media types in its messages: encoding the data and identifying its type and characteristics. HTTP borrows from MIME the notion of media types and the Content-Type header to handle type identification, as we have already seen. It similarly borrows concepts and headers from MIME to deal with the encoding issue. Here, however, we run into some of the important differences between HTTP and MIME.

Encoding was a significant issue for MIME, because it was created for the specific purpose of sending non-text data using the old RFC 822 e-mail message standard. RFC 822 imposes several significant restrictions on the messages it carries, the most important of which is that data must be encoded using 7-bit ASCII. RFC 822 messages are also limited to lines of no more than 1000 characters that end in a “CRLF” sequence.

These limitations mean that arbitrary binary files, which have no concept of lines and consist of bytes which can each contain a value from 0 to 255, cannot be sent using RFC 822 in their native format. In order for MIME to transfer these files, they must be encoded using a method such as base64, which converts three 8-bit characters to a set of four 6-bit characters that can be represented in ASCII. When this sort of transformation is done, the MIME Content-Transfer-Encoding header is included in the message so the recipient can reverse the encoding to return the data to its normal form.

Now, while this technique works, it is less efficient than sending the data directly in binary, because base64 encoding increases the size of the message by 33% (three bytes are encoded using four ASCII characters, each of which takes one byte to transmit). HTTP messages are transmitted directly between client and server over a TCP connection, and do not use the RFC 822 standard. Thus, binary data can be sent between HTTP clients and servers without the need for base64 encoding or other transformation techniques. Since it is more efficient to send the data unencoded, this may be one reason why HTTP’s developers decided to not make the protocol strictly MIME compliant.


Previous Topic/Section
HTTP Entities and Internet Media Types
Previous Page
Pages in Current Topic/Section
1
23
Next Page
HTTP Data Length Issues, "Chunked" Transfers and Message Trailers
Next Topic/Section

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!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



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.