Repository navigation
"A status is a code" doesn't actually mean anything #1142
Description
The definition of status simply states:
A status is a code.
It then follows up with some more specification definitions of particular types of statuses, which imply that by "code" you mean "an integer, probably somewhere in the range 1-1000 or so".
Since "code" doesn't have a definition, and the English definition doesn't generally map to "integer in some range", this dfn should instead actually specify what a status is: a positive (or non-negative?) integer, probably in some specified range.
Activity
annevk commentedon Jan 21, 2021
Thanks, turns out this is a bit of a mess I had not previously looked into in detail (beyond 699, which has test coverage).
1and001server-side.)(I agree that we should say this is a number by the way. For the purposes of Fetch I suspect we want at least the range 0-999 to be supported, but perhaps not 1-99, depending on whether user agents are willing to be stricter there.)
cc @whatwg/http
Bugs filed:
MattMenke2 commentedon Jan 21, 2021
The fact that they're truncated to 16-bits in Chrome is weird - looking at the code, they're treated as signed 32-bit ints down through the top level of the render process code. That has its own issues, obviously - the int parser looks like it overflows/underflows to the max int/min int values, but seems better than the 16-bit overflow behavior described.
Another "fun" behavior is that Chrome adds a 200 status code if there is no status code, but I guess that's should be treated as another issue entirely.
shacharz commentedon Jan 21, 2021
In my experience 3xx usually are not returned to the caller and handled by fetch/HTTP directly
MattMenke2 commentedon Jan 21, 2021
What about 3xx headers without a location header, or 3xx-es without an assigned meaning?
annevk commentedon Jan 21, 2021
@MattMenke2 ah, I suspect the mapping from 32- to 16-bit happens at the IDL layer (
statusisunsigned shortwhich is 16-bit). (And yeah, I didn't delve into 206, 3xx, and such here as we already have issues or they are already adequately tested. If I remember correctly 3xx withoutLocationor assigned meaning are passed to the caller.)HTTP/1 status code tests
annevk commentedon Feb 1, 2021
@tabatkins I think the ideal outcome here is a number in the range 0 to 999, inclusive. Do you need to look at this field for a specification? Note that we have "ok status" which is what specifications generally use if they need this.
Clarify what a status is
HTTP/1 status code tests
Clarify what a status is
tabatkins commentedon Feb 1, 2021
No, I was just looking over Fetch for a different purpose, and happened to run across this and was like "hey, this isn't very good, huh".
Bug 1689979 [wpt PR 27421] - HTTP/1 status code tests, a=testonly
Bug 1689979 [wpt PR 27421] - HTTP/1 status code tests, a=testonly
Bug 1689979 [wpt PR 27421] - HTTP/1 status code tests, a=testonly
Bug 1689979 [wpt PR 27421] - HTTP/1 status code tests, a=testonly
Bug 1689979 [wpt PR 27421] - HTTP/1 status code tests, a=testonly
mikkorantalainen commentedon Jun 2, 2024
The spec says
A <dfn export>redirect status</dfn> is a <a for=/>status</a> that is 301, 302, 303, 307, or 308.– should it also mention that real world browsers do honorLocationheader for a redirect with any status code?annevk commentedon Jun 3, 2024
Not all browsers do that and that's considered a bug.
Bug 1689979 [wpt PR 27421] - HTTP/1 status code tests, a=testonly