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 HTTPs developers decided to not make the protocol strictly MIME compliant.
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.