On Fri, Mar 12, 2010 at 12:09 AM, <[email protected]> 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 <[email protected]> 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
