"A status is a code" doesn't actually mean anything

[tabatkins]

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.

[annevk]

Thanks, turns out this is a bit of a mess I had not previously looked into in detail (beyond 699, which has test coverage).

• 0-99: these are returned as-is. Firefox returns 0 as 200. (Probably requires further testing between returning 1 and 001 server-side.)
• 1xx: these are not returned to the caller and handled by fetch/HTTP directly. Generally by waiting for the final response.
• 2xx-5xx: generally returned to the caller, specifics handled by Fetch already (if not, Fetch needs a patch).
• 6xx-9xx: returned to the caller.
• 1000+: Safari treats these as a network error. Chrome and Firefox keep trucking, but their maximum returned value is 65535 after which they start wrapping which feels like a security issue of sorts, e.g., 65736 is returned as 200 and 131072 as 0.

(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:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1687903
• https://bugs.chromium.org/p/chromium/issues/detail?id=1169011

[MattMenke2]

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]

In my experience 3xx usually are not returned to the caller and handled by fetch/HTTP directly

[MattMenke2]

What about 3xx headers without a location header, or 3xx-es without an assigned meaning?

[annevk]

@MattMenke2 ah, I suspect the mapping from 32- to 16-bit happens at the IDL layer (status is unsigned short which 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 without Location or assigned meaning are passed to the caller.)

[annevk]

@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.