Skip to content
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

Can't handle URLs with @ character in userinfo section #328

Closed
sethmlarson opened this issue Sep 8, 2019 · 2 comments · Fixed by #1159
Closed

Can't handle URLs with @ character in userinfo section #328

sethmlarson opened this issue Sep 8, 2019 · 2 comments · Fixed by #1159
Labels
bug Something isn't working

Comments

@sethmlarson
Copy link
Contributor

sethmlarson commented Sep 8, 2019

>>> import httpx
>>> httpx.URL("https://[email protected]:[email protected]")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/sethmlarson/Desktop/http3/httpx/models.py", line 112, in __init__
    raise InvalidURL("No host included in URL.")
httpx.exceptions.InvalidURL: No host included in URL.

This is a common use-case for proxies and websites using email addresses as usernames for authentication.

This might require a change in rfc3986 or the way we parse URLs. :)

@sethmlarson sethmlarson added the bug Something isn't working label Sep 8, 2019
@cansarigol
Copy link
Contributor

Hi @sethmlarson I've pushed a PR about this topic. Could your review it?

@tomchristie
Copy link
Member

So, something I think we may want to re-review prior to 1.0 is which internal URL parsing implementation is really our best option. This issue (and perhaps also #858, although maybe that's exclusively an issue on our side?) currently means that we're a little less robust on URL parsing than the wonderfully battle hardened urllib3, which is something we ought to resolve.

Making a change here wouldn't have any affect on our public API. That's tied down and looks that way we want. But this could potentially change which dependancies we choose to ship with.

Some options here are...

  • Stick with rfc3986. Because we're doing just fine really. Let's just make sure we're contributing our time to helping getting this issue resolved.
  • Consider irl.
  • Switch to the urllib3 implementation, possibly by vendoring just the URL parsing into a (properly licensed and credited) slimline stand-alone package that just implements plain functions for url_parse and url_join, that only deal with super plain named-tuple-like arguments.

Of those three options, the last seems like it'd be the most robust approach, since urllib3 have been doing this for years. Having said that, I don't really have enough context about which of these three options the urllib3 team themselves would consider to be most suitable.

No doubt @sigmavirus24 and @sethmlarson both have far more insight into this, tho I don't want to push for anyone's time here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants