Reality of "Transfer-Encoding"?
- Note that I'm very new to exploration of the details of the HTTP spec, much
less its implementation.
I would assume that, like many protocol specifications that are designed to
meet a wide range of needs, there are areas of the HTTP specification which
are less used, or rarely implemented, compared to other areas of the
specification. I wonder if there is any understanding of what areas of the
HTTP specification are essentially "moot", or are expected to not be ever
used by real-world tools?
In particular, I wonder about "Transfer-Encoding". Is this something that
is really used? In addition, how relevant are "byte ranges", and even
worse, byte ranges on entities requested with transfer-encodings?
- On Wed, 1 Aug 2001, Karr, David wrote:
> In particular, I wonder about "Transfer-Encoding". Is thisYes. AFAIK, several Squid-based projects use Transfer-Encoding to
> something that is really used?
compress entities in transfer between cooperating intermediaries. I
would imagine that wireless and similar applications make use of
Transfer- (hop-by-hop) and Content-Encoding (end-to-end).
I heard that new versions of ICAP require support for chunked transfer
> In addition, how relevant are "byte ranges",Very relevant for handling large documents. For example, Acrobat
Reader uses byte ranges to fetch (portions of) PDF files.
There are lots of Web clients that use byte ranges to fetch large
entities in small chunks (for reliability or whatever reasons). Web
crawlers use that feature as well. Our Web server log is full of 206
responses for source code/binaries downloads. I think those files get
more range requests than "normal" requests!
> and even worse, byte ranges on entities requested withNot sure, but it seems to me that correct support for
Transfer-Encoding and for ranges would yield correct support for
ranges on transfer-encoded entities.