On Fri, Mar 12, 2010 at 12:09 AM, <johansen_at_sun.com> wrote:
> On Thu, Mar 11, 2010 at 10:24:29PM +0100, Olaf van der Spek wrote:
>> On Thu, Mar 11, 2010 at 9:40 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
>> >> Again, IMO, that's a server-side bug. If apps fail due to this, it might
>> >> be a good idea to fix stuff regardless.
>> >
>> > Most client-side app authors cannot affect the server side apps, their bugs
>> > or setup issues. They need to live with them.
>>
>> Sure, I understand. They can by removing the accept encoding header.
>> I simply fail to see why the default should be like it is because of this.
>
> Daniel and Gary have beaten me to a number of excellent points about
> such a change.  I'm not clear why you think this is necessary.  Earlier
> in the conversation, you agreed that changing the default encoding is
> unlikely to result in a performance gain for the majority of clients.

Did I agree on that? I do agree it's not guaranteed to improve
performance for everyone.
I don't know (enough) about libcurl uses to say whether that applies
to the majority.

> The argument that this will reduce code complexity seems tenuous, since
> changing defaults will be a flag day for existing libcurl applications,
> breaking backwards compatibility.

Don't you mean exposing bad configurations/bugs intead of breaking
backwards compatibility?

> I do take your point about the server configuration, but in my
> particular case, it's not the server configuration that controls the
> compression behavior; it's the server's code.  In addition to the

What server is that? What's the behaviour of that server regarding compression?

> client-side changes, I'd have to work with the upstream developers to
> patch and re-deploy the server.  It's not obvious how this reduces
> complexity for anyone.

What client-side changes would be necessary?
I don't say it reduces complexity for everyone.

> As Daniel observed, having the libcurl use a minimal set of options by
> default is preferable.  There are a multitude of server implementations
> that implment optional features in different and surprising ways.

Should we stick to HTTP/1.0 too then? ;)

> Although this analogy is imprecise, getting your TCP options incorrectly
> negociated is a similar compatibility problem and a huge hassle.  If I
> have a router between a pair of hosts that doesn't understand my TCP
> window scaling options, but both hosts do, I can get strangely mangled
> frames, dropped packets, and have the application fail in strange ways.
> The hosts correctly negociated their options, but out-dated hardware in
> the middle interfered.  Most TCP stacks now enable these options by
> default, but I know a number of sysadmins who prefer to override these
> defaults and disable window scaling, because they still can't guarantee
> reliable behavior to their clients.

I guess this is comparable to HTTP pipelining issues.

However, window scaling is a useful feature in certain cases and in
the long-term, the bad routers will get fixed.
I feel the same applies to HTTP compression.

I also argued to get HTTP compression enabled by default server-side,
as I saw too many servers with compression disabled. People are likely
to stick with defaults.

> While TCP and HTTP are obviously different creatures, I agree with
> Daniel's cautious approach.  Not all servers implement these features as
> well as others, not all servers are as well configured as others.
> However, by using the minimal set of options as the default, it's more
> likely that the average libcurl request will be successful when
> confronted with a weird or misconfigured server.

What kind of failure are we talking about?
I thought it was merely a performance issue of maybe trying to
compress uncompressable content.

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