{{ message }}
Repository navigation
Conversation
ResponseInit.statusText is a WebIDL ByteString, so converting a string containing any code unit above 0xFF throws a TypeError. "Initialize a response" then throws a TypeError if a non-empty statusText does not match the HTTP reason-phrase production, *( HTAB / SP / VCHAR / obs-text ), where obs-text is %x80-FF. The issue asks for ASCII validation, but that is stricter than the spec: obs-text admits 0x80-0xFF, and WPT's response-init-001 expects a statusText of "\x80" to be accepted and returned as-is. workerd's existing check rejects only code units below 0x20. With pedantic_wpt enabled, statusText is now validated as the spec requires. Compared with the existing check, that: - rejects code units above 0xFF, such as U+0100 (WPT's response-error.any.js); - rejects DEL (0x7F), which is not a VCHAR; and - accepts HTAB, which the reason-phrase production allows. KJ HTTP rejects only CR, LF and NUL in a status line, so a tab is safe to send. Compatibility: all three changes are gated behind the existing pedantic_wpt flag, which has no enable date. The new rejections throw on input that is currently accepted, and accepting HTAB is gated alongside them so that behaviour without the flag is unchanged. Testing: tests were not run locally because a WARP outage made the cfdata.org dependency, remote cache and credential hosts that edgeworker's bazel needs unreachable. CI is the verification. Fixes #4971 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
npaun
force-pushed
the
npaun/pedantic-wpt-status-text-bytestring
branch
from
October 20, 2026 04:48
abe170a to
1c8e493
Compare
npaun
marked this pull request as ready for review
October 20, 2026 04:51
Contributor
jasnell
approved these changes
Oct 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ResponseInit.statusTextis a WebIDL ByteString, so any code unit above 0xFF must throw aTypeError. "Initialize a response" then also throws aTypeErrorif a non-empty statusText doesn't match the HTTP reason-phrase production,*( HTAB / SP / VCHAR / obs-text ), where obs-text is%x80-FF.The issue asks for ASCII validation, but that's stricter than the spec. obs-text allows 0x80–0xFF, and WPT's
response-init-001expects"\x80"to be accepted and returned as-is.With
pedantic_wptenabled, compared with the existing check (which rejects only code units below 0x20), statusText validation now:response-error.any.js)Fixes #4971
Compatibility
All three changes are gated on the existing
pedantic_wptflag.Reviewer notes
"\x80"→C2 80), not as the single byte.