Summary

The Fetch spec gives a response an empty status message unless something sets it. ResponseInit.statusText defaults to "", and only the scheme fetch steps set a value: OK for data:/about:blank, and OK/Partial Content for blob:. workerd instead derives the reason phrase from the status code, so new Response(null, { status: 404 }).statusText is "Not Found", and the same goes for Response.json() and Response.redirect().

With pedantic_wpt enabled:

• An unset statusText is "".
• A Response initialized from another Response (constructor or Response.json()) copies its status message exactly.
• fetch() responses keep the reason phrase the server sent, even when it matches the default.

data: URL fetches now set "OK" explicitly, which is the value they already reported. workerd doesn't fetch blob: or about: URLs.

The HTTP reason phrase on the wire is unchanged. An unset status message still sends the conventional phrase (new getReasonPhrase()), so HTTP clients see no difference. Error messages that include the status, such as Fetcher's put()/get() helpers, use the same phrase.

Fixes #4973

Compatibility

Every visible change is gated on the existing pedantic_wpt flag. Without it, statusText behaves as before. WPT always runs with pedantic_wpt (build/wpt_test.bzl), so the statusText expected failures in response-init-001, response-static-redirect and response-static-json are removed from both fetch WPT configs.

Open issue: statusText across JS RPC when the two Workers' flags differ

When a Response crosses JS RPC, Response::serialize sends the stored status message, and omits it entirely when it's unset. deserialize rebuilds the Response without one, so the receiving Worker's flag decides what "unset" means. But "unset" means different things on each side: without pedantic_wpt it means "use the default phrase", and with it it means "".

If the two Workers' pedantic_wpt settings differ, they see different values for the same Response:

The last row is the worst. Without the flag, makeHttpResponse doesn't store a reason phrase that matches the default. So a pedantic_wpt Worker that receives a proxied fetch result over RPC reports "", even though the origin really sent Not Found. That information is lost.

Mixed settings aren't hypothetical: RPC between Workers owned by different teams is common. It also matters more if pedantic_wpt ever gets an enable date, because then mixed settings become the normal state during the transition.

Proposed fix: make the serialized form say exactly what the sender sees. serialize would write getStatusText(js), the sender's effective value, explicitly, so the receiver always sees what the sender saw. Pieces:

• A pedantic_wpt sender's unset value then arrives as an explicit "". If a receiver without the flag returns that Response to a client, getReasonPhrase() would send an empty reason phrase, because it only falls back when the value is unset. getReasonPhrase() should therefore also fall back on "". That changes the wire for an explicitly empty statusText (today it sends an empty phrase), but HTTP clients don't depend on the reason phrase.
• An older runtime receiving this just sees an explicit statusText, so there's no version-skew problem.

This isn't implemented in this PR yet. Feedback welcome on whether to fold it in here, before this lands.