You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand this is open source software provided for free and that I might not receive a timely response.
I am positive I am NOT reporting a (potential) security
vulnerability, to the best of my knowledge. (These must be shared by
submitting this report form instead, if
any hesitation exists.)
I am willing to submit a pull request with reporoducers as xfailing test cases or even entire fix. (Assign this issue to me.)
Describe the bug
If a URL has an explicit port of 0 and a scheme with a default port (such as http), then the port and explicit_port attributes disagree on what the port is.
To Reproduce
import yarl
u = yarl.URL("http://a.co:0")
assert u.port == u.explicit_port
Expected behavior
If explicit_port is not None, then port should be the same as explicit_port.
Logs/tracebacks
Python 3.10.12 (main, Sep 11 2024, 15:47:36) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import yarl
>>> u = yarl.URL("http://a.co:0")
>>> assert u.port == u.explicit_port
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AssertionError
>>> u.port
80
>>> u.explicit_port
0
I discovered this because Hypothesis can generate such a URL from its hypothesis.provisional.urls strategy. I think yarl's implementation of port (as self.explicit_port or self._default_port) is wrong because the URL grammar permits the port to be 0 (the production is just port = *DIGIT), but I can't think of a situation where a URL with port 0 would be useful.
The text was updated successfully, but these errors were encountered:
Thanks for the report! Outside of URLs, port 0 may have different semantics assigned. For example, it can be a so-called "ephemeral port" that is passed into the socket bind syscalls and then the kernel assigns an unoccupied port that nobody claimed, at which point it turns into a concrete port with a non-zero number.
I can imagine that someone may want to represent a pre-binding URL for logging purposes. Or for when an interactive app doesn't bind to a port until a user clicks the button.
I can also imagine 0 having different semantics for non-HTTP URLs (yarl is agnostic, after all).
So I'd say — send us an xfailing test and perhaps some Hypothesis tests, for starters.
No rush, though — we're leading an aiohttp sprint day on Saturday and this might be a good issue for the participants to look into.
Please confirm the following
vulnerability, to the best of my knowledge. (These must be shared by
submitting this report form instead, if
any hesitation exists.)
Describe the bug
If a URL has an explicit port of
0
and a scheme with a default port (such ashttp
), then theport
andexplicit_port
attributes disagree on what the port is.To Reproduce
Expected behavior
If
explicit_port
is notNone
, thenport
should be the same asexplicit_port
.Logs/tracebacks
Python Version
multidict Version
propcache Version
yarl Version
OS
Ubuntu 22.04
Additional context
I discovered this because Hypothesis can generate such a URL from its
hypothesis.provisional.urls
strategy. I think yarl's implementation ofport
(asself.explicit_port or self._default_port
) is wrong because the URL grammar permits the port to be 0 (the production is justport = *DIGIT
), but I can't think of a situation where a URL with port 0 would be useful.The text was updated successfully, but these errors were encountered: