Skip to content

Fix URL lexer dropping the host and path when a port is present#3739

Open
chatman-media wants to merge 1 commit into
Automattic:masterfrom
chatman-media:fix/url-lexer-port-truncation
Open

Fix URL lexer dropping the host and path when a port is present#3739
chatman-media wants to merge 1 commit into
Automattic:masterfrom
chatman-media:fix/url-lexer-port-truncation

Conversation

@chatman-media

Copy link
Copy Markdown

URLs with an explicit port lose everything after the scheme. http://localhost:8080/api gets tokenized with only http:// as the URL, and localhost:8080/api ends up treated as ordinary text (so the host and path get spell-checked).

The cause is in lex_hostport: when a : follows the host, it looks for the end of the port by scanning for the first non-digit from the start of the host rather than from after the colon. Since the host starts with a letter (or the scan stops at the first dot), that search returns almost immediately and the port comes out zero-length, ending the URL right after the scheme.

This scans the port digits from just after the colon, and leaves the colon alone if there's no port behind it. Added a few cases to the url tests (localhost:8080, with a path, and an IP with a port).

When a URL had an explicit port (http://localhost:8080/api), lex_hostport
scanned for the end of the port starting from the beginning of the
host instead of after the colon. The host's first character is a letter
(or the scan stops at the first dot), so the search for the first
non-digit returned almost immediately and the port was treated as
zero-length. The URL token then ended right after the scheme, leaving
the host, port, and path to be tokenized as ordinary prose and spell-checked.

Scan the port digits from just after the colon, and leave the colon
unconsumed when no digits follow it.
@hippietrail

Copy link
Copy Markdown
Collaborator

Yes I've made some toy projects recently annotated text tokenized by Harper, and sometimes whole URLs are interpreted as a single URL token and sometimes only the host is interpreted as a host token and all the other parts are interpreted as words and punctuation. But I haven't yet figured out the pattern or whether it's plain text input vs Markdown input.

I don't think the ones I encountered used the port, so I suspect there's more than one problem in our URL parsing.

@elijah-potter

Copy link
Copy Markdown
Collaborator

@chatman-media, have you read our agent policy?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants