Support arbitrary status codes

[Manishearth]

While the spec goes up till status code 599, we should probably support arbitrary three-digit codes.

This test fails now because of it (I don't mind allowing that failure for now, but I'd like a solution where hyper doesn't outright reject the code).

[Manishearth]

(We're using RawStatus initialized to 0, and we're getting that it stays 0 instead of becoming 699)

[reem]

This is rather unfortunate, since adding an Extension(u16) variant wouldn't allow the compiler to optimize Status down to two bytes, but instead it would have to have two bytes for the discriminant and two bytes for all values. If we want Extension(uint) it gets even worse, with Status being six bytes.

I'm not sure how big a deal this is (it at all) but it's unfortunate.

[Manishearth]

Since Servo uses RawStatus, perhaps some way to pass it down to RawStatus would work?

I agree that we should try to optimize Status as much as possible.

Another option is to add variants till 999 (with a macro?); which is still 2 bytes.

[seanmonstar]

I'd venture to say that that test itself is broken. The XHR spec itself says that if a status is not within 200-599, then to throw a RangeError: https://fetch.spec.whatwg.org/#concept-response-response

[Manishearth]

That's the fetch standard, not XHR. XHR references fetch, but that specific portion is for fetch(), not XHR::send()

This is the relevant bit of the fetch spec for handlign responses (XHR defines the actual handling of the task here )

[dpc]

Why is StatusCode an enum? When I see around 400 lines of:

  /// 132 (unregistered)
  Code132 = 132,

It seems to me it should be struct StatusCode ( u16 ) with some helpers / static constants for common codes.

[seanmonstar]

Because by being an enum, it limits the values you might pass.

On Sat, Dec 13, 2014, 2:20 PM Dawid Ciężarkiewicz notifications@github.com
wrote:

Why is StatusCode an enum? When I see around 400 lines of:

/// 132 (unregistered)
Code132 = 132,

It seems to me it should be struct StatusCode { u16 } with some helpers /
static constants for common codes.

—
Reply to this email directly or view it on GitHub
#177 (comment).

[dpc]

I'm just playing so don't bash me too much if you don't like it, but would that work?

dpc@9c2b06b

The only way to create a custom StatusCode is StatusCode::from_code and checks can be added there, and for common codes there are constants.

I don't like the fact that consts are defined in hyper::status namespace instead of hyper::status::StatusCode though. Is there a way to move this consts in right namespace somehow?

Also, I've removed all the the unregistered codes. Their constants could be restored though, and if the problem with the namespace is solved, this could been a drop-in replacement.

[seanmonstar]

@dpc hm, i'm coming around to that design. I'd likely change from_code to unregistered(), and also add Deref<u16> to it...

[reem]

@seanmonstar I wouldn't want Deref<u16> since that would get us a bunch of u16 methods that are undesirable or incorrect to use.

[kud1ing]

Maybe another option: adding an enum value Unhandled(uint) that contain values beyond the spec.
This statically isolates specified and non-specified status codes.

[Manishearth]

That doubles the size of the struct though. Perhaps with a smaller int type it would get squashed by alignment.

[seanmonstar]

Actually we can't. It's currently a c-enum, and they can't also have variants containing values.

[dpc]

@seanmonstar : What's the purpose of Deref? To get the raw code? Wouldn't explicit fn to_raw(&self) -> u16 be OK?