Uh oh!
There was an error while loading. Please reload this page.
url: treat empty port as default - #483
Conversation
When parsing URLs, treat an empty port (eg `http://hostname:/`) as if it were unspecified. RFC 3986 says: > URI producers and normalizers SHOULD omit the port component and its > ":" delimiter if port is empty or if its value would be the same as > that of the scheme's default. (Emphasis on the "SHOULD" is mine.) This indicates that URIs MAY be produced with an empty port and the `:` delimiter. Thus, we stop failing if we end host parsing at the port delimiter.
indutny
commented
Jun 26, 2019
cc @nodejs/http : are we aware of any possible side effects that might happen in Node.js after landing this? |
indutny
commented
Jun 26, 2019
@ethomson thank you for an excellent PR! The change looks great. It has to be considered in the context of Node.js too, however. Let's wait for @nodejs/http to get better understanding of interactions of this PR and Node core. |
indutny
commented
Jun 26, 2019
As a side note, I wonder if libgit2 might be interested in using llhttp instead of |
ethomson
commented
Dec 8, 2019
mgorny
commented
Feb 21, 2020
@nodejs/http, ping. |
sam-github
commented
Mar 17, 2020
@nodejs/http |
| case s_http_host_v6: | ||
| case s_http_host_v6_zone_start: | ||
| case s_http_host_v6_zone: | ||
| case s_http_host_port_start: |
There was a problem hiding this comment.
This changes the behavior of http_parser_parse_url(is_connect=1) in that it'll now allow CONNECT hostname: as valid input, doesn't it?
When parsing URLs, treat an empty port (eg
http://hostname:/) as if it were unspecified. RFC 3986 says:(Emphasis mine.) This indicates that URIs MAY be produced with an empty port and the
:delimiter.Thus, we stop failing if we end host parsing at the port delimiter.