After deleting my comment, turns out there's still a bug.

It only uses an absolute API if it detects you are using a proxy server for your given URI.

Double check your proxy settings in etc/web/config.props

After deleting my comment, turns out there's still a bug.

After deleting my comment, turns out there's still a bug.

After deleting my comment, turns out there's still a bug.

(Really shouldn't have jumped the gun on deleting my comments above...)

So, the issue that remains is I'm getting:

sys::IOErr: Unsupported Content-Encoding: utf-8

When I do WebClient.readRes.

The resCode and resHeaders seem to be there.

So, it seems like something else is being included that is bugging out WebClient.

Running the same URI through curl does not produce any problems (and gives me the requested content).

Here's the response line/headers:

HTTP/1.1 200 OK
x-amz-id-2: KyKYVtQrpDu6IoiuaKQKIpGwDECqkOpvHSmU1Mj/DkWVJcOkZ5gQmiHUNmJfPEb/hn1I/PGTJeE=
x-amz-request-id: FE108CD3718699E9
Date: Wed, 28 Feb 2018 00:26:09 GMT
Last-Modified: Tue, 27 Feb 2018 19:05:33 GMT
ETag: "7ff9f51caf577517b59d5ed26b17b4b0"
Content-Disposition: attachment;filename="export.csv"
Content-Encoding: UTF-8
Accept-Ranges: bytes
Content-Type: application/ms-excel; charset=UTF-8
Content-Length: 639255
Server: AmazonS3

Passing the response body into curl gives this for the first 16 characters:

"Account_ID",
efbbbf224163636f756e745f4944222c // In Hex

It seems like that's a byte order mark? I suspect that's what's causing WebClient to bug out?

EDIT: Ahh that's why:

default: throw IOErr("Unsupported Content-Encoding: $ce")

So, it seems it's unhappy with the server giving the header Content-Encoding: UTF-8.

Is there any way that I can override this?

That isn't a valid content-encoding which defines a compression encoding (not a character encoding).

See MSDN

Yup, I noticed that as well. I sent that to the API developers. However, rather then wait for then, is there any way I can circumvent this check, short of copying the whole code for WebClient into my pod with this variation?

s there any way I can circumvent this check, short of copying the whole code for WebClient into my pod with this variation?

No, that is a pretty fundamental low-level hook which determines how to map the raw socket input stream to the application level input stream