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.
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.

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
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.

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.

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.

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.

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