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 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 Entities and Internet Media Types 1 2 3 HTTP Data Length Issues, "Chunked" Transfers and Message Trailers

HTTP's Two-Level Encoding Scheme

This would seem to be an area where HTTP was simpler than MIME—since there is no need to encode the entity, there is no need for the Content-Transfer-Encoding header, and we have one less thing to worry about. Ha, nice try! J It is true that HTTP could have simply been designed so that all entities were just sent one byte at a time with no need to specify encodings. But the developers of the protocol recognized that this would have made the protocol inflexible. There are situations where it might be useful to transform or encode an entity or message for transmission, and then reverse the operation upon receipt.

This effort to make HTTP flexible resulted in a system of representing encodings that is actually more complicated than MIME’s. The key to understanding it is to recognize that HTTP/1.1 actually splits MIME’s notion of a “content transfer encoding” into two different encoding levels:

• Content Encoding: This is an encoding that is applied specifically to the entity carried in an HTTP message, to prepare or package it prior to transmission. Content encodings are said to be “end-to-end”, because the encoding of the entity is done once before it sent by the client or server, and only decoded upon receipt by the ultimate recipient: server or client. When this type of encoding is done, the method is identified in the special Content-Encoding entity header. A client may also specify what content encodings it can handle, using the Accept-Encoding header, as we will see in the topic on content negotiation.
  
  
• Transfer Encoding: This is an encoding that is done specifically for the purpose of ensuring that data can be safely transferred between devices. It is applied across an entire HTTP message, and not specifically to the entity. This type of encoding is “hop-by-hop” because a different transfer encoding may be used for each hop of a message that is transmitted through many intermediaries in the request/response chain. The transfer encoding method, if any, is indicated in the Transfer-Encoding general header.

HTTP Entities and Internet Media Types 1 2 3 HTTP Data Length Issues, "Chunked" Transfers and Message Trailers