While working on a gzip test script, I discovered that I forgot to update the
curl front-end to support gzip as well. That highlighted two weaknesses
in curl's content-encoding support. First, the CURLOPT_ENCODING semantics
requires that the application know which encodings are supported by the curl
library; there's no way to say "request all supported content-encodings".
That's easily changed by specifying that an empty (not NULL) string set for
CURLOPT_ENCODING means to request all supported encodings. I can't think of
any unexpected side effects of this change.

Secondly, there's no way to see what Content-Encoding the server actually
ent on an CURLE_BAD_CONTENT_ENCODING return code or if CURLOPT_ENCODING isn't
set. In the more general case, I don't see a way to look at arbitrary
HTTP headers except by enabling CURLOPT_HEADER and parsing them myself.
This is a less severe problem than the first.

The attached patch against CVS adds gzip support to the front-end. If the
consensus is that the first option above is suitable, I'll make that quick
change.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf