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.

Sign up for GitHub

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

Jump to bottom

Codepoint U+005B not allowed at position1 in '[::1]' #29

Closed
philbert opened this issue Nov 21, 2016 · 5 comments
Closed

Codepoint U+005B not allowed at position1 in '[::1]' #29

philbert opened this issue Nov 21, 2016 · 5 comments

Comments

@philbert
Copy link

I believe this to be a bug with idna rather than in requests but I think that @kennethreitz should probably be aware of this too:

Using python 3.4 and requests 2.12.1 I tried to get this URL:
requests.get('http://[::]:5000/files')

Which returns this bunch of errors:

python3 fileclient.py
Traceback (most recent call last):
  File "/usr/local/lib/python3.4/dist-packages/requests/packages/idna/core.py", line 327, in uts46_remap
    raise IndexError()
IndexError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.4/dist-packages/requests/models.py", line 370, in prepare_url
    host = idna.encode(host, uts46=True).decode('utf-8')
  File "/usr/local/lib/python3.4/dist-packages/requests/packages/idna/core.py", line 340, in encode
    s = uts46_remap(s, std3_rules, transitional)
  File "/usr/local/lib/python3.4/dist-packages/requests/packages/idna/core.py", line 332, in uts46_remap
    _unot(code_point), pos + 1, repr(domain)))
requests.packages.idna.core.InvalidCodepoint: Codepoint U+005B not allowed at position1 in '[::1]'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "fileclient.py", line 55, in <module>
    buy_file()
  File "fileclient.py", line 17, in buy_file
    response = requests.get(url=server_url+'files')
  File "/usr/local/lib/python3.4/dist-packages/two1/bitrequests/bitrequests.py", line 169, in get
    return self.request('get', url, max_price, **kwargs)
  File "/usr/local/lib/python3.4/dist-packages/two1/bitrequests/bitrequests.py", line 134, in request
    response = requests.request(method, url, **kwargs)
  File "/usr/local/lib/python3.4/dist-packages/requests/api.py", line 56, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/local/lib/python3.4/dist-packages/requests/sessions.py", line 474, in request
    prep = self.prepare_request(req)
  File "/usr/local/lib/python3.4/dist-packages/requests/sessions.py", line 407, in prepare_request
    hooks=merge_hooks(request.hooks, self.hooks),
  File "/usr/local/lib/python3.4/dist-packages/requests/models.py", line 302, in prepare
    self.prepare_url(url, params)
  File "/usr/local/lib/python3.4/dist-packages/requests/models.py", line 372, in prepare_url
    raise InvalidURL('URL has an invalid label.')
requests.exceptions.InvalidURL: URL has an invalid label.

I downgraded to requests 2.11.1 (prior to the idna update) and now my code works again.
@jribbens
Copy link
Collaborator

It seems to me that this is a bug in requests, not idna. idna's functions expect to be passed domain names, not IP literals - requests should be detecting the presence of the literal in the URL and not passing it to idna in the first place.

@philbert
Copy link
Author

@jribbens thanks for the input.
@kennethreitz can you confirm and if so would you like me to close this issue and raise it against requests?

@kjd
Copy link
Owner

kjd commented Nov 23, 2016

Concur with @jribbens that this is the result of passing invalid input to a function that expects domain names. There may be an argument for adding a flag to enable a pass-through for situations where the input could include IP addresses, but the default should be protocol adherence and on that front the string is not a valid domain.

I suspect it is likely more desirable for everyone for downstream users like the requests library to distinguish between domains and IP addresses before passing the host part for normalization/conversion.

As an aside, having personally run into similar problems before, there may be a need to normalize/convert IP addresses which can have multiple valid representations too. For example, such that "0000:0000::1" == "::1". Even IPv4 addresses have normalization quirks — such as zero padding, or being represented as integers rather than dotted quads:

$ curl http://3627729486/
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
...

@kjd
Copy link
Owner

kjd commented Nov 23, 2016

kennethreitz/requests#3695 seems to address this issue.

@philbert
Copy link
Author

@kjd thanks for finding that! I'll close this issue since the fix for requests is on the way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@kjd @jribbens @philbert