Document HTTP encoding limitations for Fetch plugins #406
Description
In a particular case, I had a server that was always returning a response with
Content-Encoding: gzip:
curl -sS -D - "https://www.swi-prolog.org/download/stable/src/" -o /dev/null
regardless of content negotiation via Accept-Encoding: in the request.
Well, it was. This got fixed yesterday so it no longer applies. But
continuing with the issue...
Since the content negotiation was not working properly, I believe that using
Fetch::HTTPTiny, Fetch::CurlCommand, or Fetch::Wget plugins would break
when trying to pass the text/html content as they would not be able to decode
the content. By changing the Fetch plugin to Fetch::LWP, the response would
be decoded properly.