Re: multi-member gzip usage

Path	csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!news.dfncis.de!not-for-mail
From	Sven Köhler <remove-sven.koehler@gmail.com>
Newsgroups	comp.compression
Subject	Re: multi-member gzip usage
Date	Wed, 11 Jul 2012 21:13:29 +0200
Lines	31
Message-ID	<a661a9F1q4U1@mid.dfncis.de> (permalink)
References	<67b51fb3-ef82-4d99-bb96-ab3ed4f1ad7b@googlegroups.com> <eli$1207101519@qz.little-neck.ny.us>
Mime-Version	1.0
Content-Type	text/plain; charset=ISO-8859-15
Content-Transfer-Encoding	7bit
X-Trace	news.dfncis.de weT2AxpzfI1tacyhyKCGLgjjNa2Vf36z7/KgQpbpbHEiZVrXTKvez/x4X1gdoBxtxXLUrl9tvr
Cancel-Lock	sha1:LHPO2IlLyjb7It09bafL7iLii/I=
User-Agent	Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120608 Thunderbird/13.0
In-Reply-To	<eli$1207101519@qz.little-neck.ny.us>
Xref	csiph.com comp.compression:1418

Show key headers only | View raw

Am 10.07.2012 21:25, schrieb Eli the Bearded:
> In comp.compression, jefflad  <jladouceur@gmail.com> wrote:
>> For instance would http 1.1 chunk encoding use this ?
> 
> I don't know if it does, but that seems a reasonable use case.

No. I think chunked transfer-encoding was invented to solve one
essential problem: if you don't know the length of the content in
advance (content-length HTTP response header), you cannot know when the
HTTP response ends. Prior to to chunked encoding, you had to read till
EOF and then throw the HTTP connection away. In order to allow the
re-use of the connection, you send the data in chunks, terminating the
stream of chunks with a zero length chunk. It's simply another way of
encoding an EOF. No content-length header is needed.

Also, wikipedia states, that gzip and chunk encoding are at different
layers: content-encoding (gzip) and transfer-encoding (chunks):
http://en.wikipedia.org/wiki/Chunked_transfer_encoding
So first, the data is gzipped, then the gzip data is split into chunks.

A HTTP-oriented use-case of multi-member gzip could be the following:
If the server wants to perform a flush (i.e. emptying any buffers,
making sure any data sent so far successfully arrives at the client),
the server could terminate the current member and start a new one.
But aren't there other means of flushing? Also, I don't know whether
some webservers actually implement flushing of gzip-compressed HTTP
connections.

Regards,
  Sven

Thread

multi-member gzip usage jefflad <jladouceur@gmail.com> - 2012-07-09 16:17 -0700
  Re: multi-member gzip usage Eli the Bearded <*@eli.users.panix.com> - 2012-07-10 19:25 +0000
    Re: multi-member gzip usage Sven Köhler <remove-sven.koehler@gmail.com> - 2012-07-11 21:13 +0200
  Re: multi-member gzip usage Thomas Pornin <pornin@bolet.org> - 2012-07-11 11:06 +0000

csiph-web