After digging into this with tcpdump, the issue is as follows. The _lwp_fetch method produces a request header such as the one below:
GET /path/to/file.ext HTTP/1.1 TE: deflate,gzip;q=0.3 Connection: TE, close Authorization: Basic YW5vbnltb3VzOkZpbGUtRmV0Y2hAZXhhbXBsZS5jb20= From: File-Fetch@example.com Host: my.domain.com If-Modified-Since: Wed, 07 Jun 2017 03:40:39 GMT User-Agent: File::Fetch/0.48
While some of those headers are questionable (ie the From) for an HTTP request, the one that causes this issue is the Authorization. Decoding that Basic Auth from Base64 reveals that is:
$ decode_base64("YW5vbnltb3VzOkZpbGUtRmV0Y2hAZXhhbXBsZS5jb20=") anonymous:File-Fetch@example.com
Looking into the File::Fetch source, we find this:
if ($self->userinfo) { $uri->userinfo($self->userinfo); } elsif ($self->scheme ne 'file') { $uri->userinfo("anonymous:$FROM_EMAIL"); }
(lines 593-597 of File::Fetch)
When the server gets a basic auth when it wasn't expecting one, at least for a subset of servers, it returns a 400 Bad Request error. I'm not sure the intention of putting a default basic auth in the _lwp_fetch when none was specified and when no other request method does this, but this is the reason it doesn't work, and why you need to either blacklist lwp or turn off warnings. Hope this helps those who come along after.
In reply to Re^3: HTTP response: 400 Bad Request
by DennisJBell
in thread HTTP response: 400 Bad Request
by JoeJohnston
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |