Re: Support for gzip at the server #424

In your use-case I suppose you get away with not sending content-length at
all.
>From my perspective, that seems perfectly reasonable: If the content-length
is known a priori, then it should be signaled. If it isn't, then don't.

In an ideal world this content-length signaling wouldn't be necessary at
all, but there are a vast majority of servers that simply do not handle
*any* chunked upload without content-length since their universe has
consisted entirely of a priori known size for the uploaded entities.

-=R


On Fri, Mar 14, 2014 at 2:15 PM, Michael Sweet <msweet@apple.com> wrote:

> Roberto,
>
> On Mar 14, 2014, at 5:08 PM, Roberto Peon <grmocg@gmail.com> wrote:
>
> The sender doesn't know the uncompressed size before it transmits?
>
>
> No, it doesn't.
>
> That seems.. odd...
>
>
> The client is generally rasterizing pages of content for the printer at
> some agreed upon resolution, bit depth, and color space.  This raster data
> is typically already compressed with a simple algorithm such as PackBits
> (run-length encoding) and is thus already variable-length per page with no
> way to know ahead of time how large it will be.  Add gzip to the mix and
> you *really* don't know what the final length will be.
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>