[bytestream]

Problem

Browsers strip leading and trailing ASCII whitespace from href attribute values (HTML spec), but the crawler passes them to the URL resolver verbatim. Markup like this exists in the wild:

<a href="
https://www.example.com/announcements/article">Announcement</a>

PHP's parse_url() doesn't see a scheme because the string starts with a newline, and it rewrites the control character as _, so Validator::absoluteUrl() returns null and the resolver treats the href as a relative path:

Url::parse('https://docs.example.com/2.6.1/')
    ->resolve("\nhttps://www.example.com/announcements/article")
    ->toString();
// https://docs.example.com/2.6.1/_https://www.example.com/announcements/article

Two knock-on effects: the crawler requests a URL that doesn't exist (404), and because the mangled URL lives on the crawled host, onSameHost() / onSameDomain() filters don't exclude what was actually an external link.

Fix

Trim href values before resolving them in every place the library reads one:

• GetLink / GetLinks (both getLinkUrl() and isSpecialNonHttpLink())
• Http::crawl() link discovery
• SimpleWebsitePaginator
• <link rel="canonical"> in Document
• HtmlDocument::getBaseHref() (which also covers <base> handling in GetLink, Document and the paginator)

DomQuery already trimmed attribute values, so Dom::cssSelector('a')->link() was unaffected.

Tests

Added regression tests for each of the above. composer test passes (1284 tests). composer cs reports nothing. composer stan reports the same 133 pre-existing errors as on main.

🤖 Generated with Claude Code