-
-
Notifications
You must be signed in to change notification settings - Fork 932
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
Fix url parsing of ipv6 urls on URL.replace
#1965
Conversation
49d5c0a
to
f248c0c
Compare
starlette/datastructures.py
Outdated
if not hostname: | ||
netloc = self.netloc | ||
_, _, hostname = netloc.rpartition("@") | ||
|
||
if hostname[-1] != "]": | ||
hostname = hostname.rsplit(":", 1)[0] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the new approach breaks the existing undocumented, untested functionality...
May I propose a test like this:
assert URL("http://u:p@host/").replace(hostname="bar") == URL("http://u:p@bar/")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or maybe like this:
assert URL("http://u:p@host:80").replace(port=88) == URL("http://u:p@host:88")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added, these are passing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be better to use urlunparse
or urlunsplit
from python stdlib instead of manual string concatention?
f248c0c
to
fdeaca4
Compare
@dimaqq not sure how you wanted to use |
Instead of the above, I would generally recommend to rebase your branch on top of master and then force-push your branch. |
We squash merge into master, so it's not really important how the branch is kept up to date with master or how the commits on the branch are organized. Of course a nice linear history with well described atomic commits is a huge plus as a reviewer, but we certainly don't require it. |
85464a9
to
aedcdc8
Compare
I prefer the same, my bad I didn't notice github used merge method to update branch. |
my 2c: it's best to disable GitHub's magic "update the branch" in repo settings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good and solves the problem that I had.
All of these work fine:
In [8]: URL("http://[1::fe]/123").replace(port=88, username="uu", password="pp").replace(port=None, username=None, password=None)
Out[8]: URL('http://[1::fe]/123')
There's still one gotcha, but I suspect this also didn't really work before either, the IPv6 hostname needs to be bracketed, which is a bit unexpected:
In [14]: URL("http://foo.com/123").replace(hostname="fe::1")
Out[14]: URL('http://fe::1/123')
In [15]: URL("http://foo.com/123").replace(hostname="[fe::1]")
Out[15]: URL('http://[fe::1]/123')
Which also leads, in one case to an exception when using IPv6 shorthands:
In [18]: URL("http://foo.com/123").replace(hostname="1::23").replace(port=88)
ValueError: Port could not be cast to integer value as ':23'
This path triggered same error before.
So, strictly speaking, this PR fixes #1931 and doesn't introduce a regression, I'd say let's merge it!
P.S. by comparison, other libraries take care of bracketing ipv6 addresses themselves, they don't ask the caller to do it: In [7]: yarl.URL("http://foo.com/1").with_host("123::fe")
Out[7]: URL('http://[123::fe]/1') |
To tackle this we should not be relying on |
🤔 I was under the impression that my 2c: Anyway, that can be a separate PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Co-authored-by: Florimond Manca <[email protected]>
URL.replace
Co-authored-by: Florimond Manca <[email protected]>
The starting point for contributions should usually be a discussion
Simple documentation typos may be raised as stand-alone pull requests, but otherwise please ensure you've discussed your proposal prior to issuing a pull request.
This will help us direct work appropriately, and ensure that any suggested changes have been okayed by the maintainers.