On Wed, Mar 10, 2010 at 11:43 PM, <johansen_at_sun.com> wrote:
>> That's worse than sending no header.
>
> Daniel suggested that others share their opinions about your idea.  I'm
> explaining how our system currently works, as evidence to why sending a
> full Accept-Encoding header would be problematic for existing users of
> libcurl.

Yes, I understand your case. Although in that case the code wouldn't
change much. You'd just disable that header instead of enable it in
certain cases.

> If "identity" is worse than no header, please at least offer some
> evidence as to why.

Eh, because it offers no advantage compared to no header.

>> The header tells the client what encodings it accepts/understands.
>> It's not supposed to be a mechanism for the client to tell the server
>> whether it's a good idea to compress the content.
>>
>> In your case, the server should know whether it's a good idea to compress.
>
> Maybe, but that's not the point.  We all have to exchange data with
> servers that, like the one I have to use, have a naive concept of how
> and when to use compression.  We're using CherryPy 3.X, if the
> accept-encoding header specifies a type of encoding that the server
> supports, it will make a best effort attempt to compress the data.

So because some servers don't have proper logic to decide on
compression, we should disable compression in the client by default?

>> > I don't see what's wrong with having an application explicitly request
>> > the features that it desires.
>>
>> Global code complexity...
>
> Except that's not true.  In the situation that I've described, your
> proposed change only adds complexity.

Why?
Instead of code to enable it in some cases, you have code to disable
it in the other cases.

>> > Enabling compression by default isn't necessarily going to increase
>> > performance by default.
>>
>> You mean in all cases? Or on average?
>
> I mean that it's situational, and depends upon the conditions in the
> network.

True.

>> > On low-latency high-bandwidth links, this may even cause performance
>> > to decrease.
>>
>> There's a difference between accepting compression and  requiring compresion.
>
> For some servers, yes.  But in other cases, stating that compression is
> accepted is enough to have the server attempt to compress every
> response.

I would blame the servers for that.

Olaf
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-03-11