On Wed, Mar 10, 2010 at 11:43 PM, <[email protected]> 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
