Re: [squid-users] persistent http with pushback

From: Henrik Nordstrom <[email protected]>
Date: Wed, 20 Feb 2002 17:25:35 +0100

On Wednesday 20 February 2002 15:24, Marcel Ruff wrote:

> How do the multiple parts look like if i don't know the length
> of all parts beforehand?

HTTP does not care if the reply is a single part or a multi-part
content. In the eye of HTTP the two is the same thing. Simply a
stream of data. The fact that your are sending a multipart MIME
content is a business between your server and client, not part of the
HTTP protocol.

A analoge is that filesystems do not care how many pages your Word
document is divided into. The division into pages is imposed by Word,
not the filesystem.

HTTP/1.0 cannot keep connections open for new requests unless the
full reply length is known beforehand. A HTTP/1.0 message where the
content length isn't known is terminated by closing the connection.
(and obviously the request message length must be known beforehand in
HTTP/1.0, or else the client would not be able to receive a reply)

In HTTP/1.1 keeping such connections open becomes possible by using
the chunked transfer encoding mechanism (see RFC2616 section 14.41
and 3.6.1), but as said eariler in this thread Squid is not yet
HTTP/1.1. Chunked transfer encoding is in some senses similar to
multipart MIME encoding but simpler and done at the HTTP level.
Chunked transfer encoding has no semantic impact on the transferred
data.

Multipart MIME is a semantic division of a larger entity into series
of sub-entities at the application level.

Chunked transfer encoding divides a data stream of unknown length
into smaller junks of known size for the purpose of transfer at the
protocol level, and some other minor details relating to the HTTP
protocol (not content). The application semantics of the content is
the same if it is sent in one large chunk or many small chunks.

Regards
Henrik Nordstr�m
Squid Developer
Received on Wed Feb 20 2002 - 13:49:31 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:06:28 MST