Skip to content

Document HTTP encoding limitations for Fetch plugins #406

Open
@zmughal

Description

@zmughal

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    🐞BugSomething fails that should not (not a feature)📖DocumentationNeeds new or re-worded documentation

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions