-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected exception: InvalidURL: No host specified. #4866
Comments
I double checked all the python requirements and the only outdated, from the ones mentioned above, is the I will try to upgrade that one, and report if it makes any difference. |
OK, that didn't help, although upgrading
But I really think that this is unrelated! Thanks, once again. |
@stratosgear, this looks like an issue with the URI you’re providing. If you use the code below, what is the value returned? If it’s None or empty, then this is a problem with the URI or a bug in the urlparse function in the Python standard library. from requests.compat import urlparse
URL = "http://yourURI.here"
parsed = urlparse(URL)
print(parsed.hostname) |
Hmmm, I do not think so. I used the sample you suggested (taken from here I guess) and the url is parsed correctly. I do get: I'm afraid I'll have to bite the bullet and fork requests, add additional debug statements, point to my fork, recompile the docker containers and try again, unless no other suggestions pop up... :( |
Further debugging reveals that the
As I do not understand what goes on in 'resolve_redirects' and it is difficult for me to debug it in the place this occurs due to my setup, is there anyone else that can understand what goes on in that method and why it drops the hostname....? Thanks! Note: I'm debugging from the v2.20.1 release branch. |
We do exactly what the server tells us meaning that your URL must redirect somewhere. This is not a bug in Requests and this is not a forum for helping you debug your infrastructure. It's only for actual defects in Requests, which this does not appear to be. |
For completeness sake this was an issue in our code base. There was a rogue:
that I have no idea what it was trying to achieve, Removing this, helps the url to resolve correctly. And yes, I know this is not a forum, but I did not ask anyone to help me debug my infrastructure. I honestly thought that I came across a requests bug, and I did whatever was humanly possible to debug the issue as best I could, even patching requests to help me find where the issue was. I provided, step by step progress report on what I was doing along the way. Ok, it's finally an issue in our infrastructure but that last comment was uncalled for, and really leaves me walking away from here with a bad taste in my mouth... |
I have some legacy code that calls requests like this:
Through debug statements right before that statement I see that the passed url is like:
That url, btw, correctly resolves into a 200MB file, in the browser or through a curl/wget download.
Expected Result
I'd expect my file to be downloaded (when I later try to:
Actual Result
I get the following stack trace:
Reproduction Steps
Apparently trying the request from the same-ish machine that cause the exception, is working.
What is different in the actual exception case, is that the request to download happens inside an RQ (http://python-rq.org/) worker running inside a docker container, that I do not know how to further debug. Mind you that kind of download infrastructure, was working correctly the last two years and only now it starts to have these downloading issues.
System Information
The docker container is setup like this:
This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c).
Thanks!
The text was updated successfully, but these errors were encountered: