escape non-printable characters in serialize_url

[affan-arch]

serialize_url only escapes the whitespace controls (tab, newline, cr, ff) and the url-breaking characters, and passes everything else through unchanged. that leaves the remaining non-printable code points (U+0001..U+001F, U+000B, U+007F) emitted raw, so a url token whose value holds one of them, which you can get from input like url(\1), serializes to a literal control byte inside the url(). the tokenizer treats those bytes as non-printable and rejects them, so that output re-parses as a bad-url error rather than the token it came from. i ran into it feeding serialize output back through the parser. this hex-escapes the remaining control points the same way the whitespace ones already are, so the value stays stable across a serialize then re-parse cycle. the change is contained to serialize_url, with a small round-trip test alongside the existing serializer tests.

[liZe]

Hi,

What’s your real-life use case?

[affan-arch]

honestly it came out of round-tripping rather than a specific app. i was feeding serialize output back through parse_component_value_list to check they stay inverse, and url tokens holding a control point (reachable from input like url(\1)) come back as a bad-url error instead of the original token. so the case is round-trip stability, treating serialize then parse as lossless. if that's not something you want to guarantee here, happy for you to close it.

[liZe]

honestly it came out of round-tripping rather than a specific app

Honestly, you round-trip with random open-source projects, just like others run in a park or go fishing.

if that's not something you want to guarantee here, happy for you to close it.

Honestly, what I want to guarantee is my mental health. Honestly, that’s hard to talk to bots all the day long.

Honestly, read the guidelines and don’t open new PRs or issues on our projects.