http: Support custom status code

Currently, hyper and this crate only support status code from [100, 600), otherwise will cause error InvalidStatusCode, which make parse a Response with custom code failed eventually.

For example:

HTTP/1.1 6xx status code 6xx

....

will cause

TRACE:hyper::proto::conn                        : Conn::read_head
TRACE:hyper::proto::h1::parse                   : Response.parse([Header; 100], [u8; 447])
TRACE:hyper::proto::h1::parse                   : Response.parse Complete(409)
TRACE:hyper::proto::conn                        : State::close_read()
DEBUG:hyper::proto::conn                        : parse error (Invalid Status provided) with 447 bytes
TRACE:tokio_proto::streaming::pipeline::advanced: process_out_frame
ERROR:tokio_proto::streaming::pipeline::client  : pipeline error: An error occurred.

But, sometime, some service will define custom status code, especially in some RESTful API.

So, I think it is fine to support custom code and reason.

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 16 (3 by maintainers)

Links to this issue

Most upvoted comments

@carllerche I have an interface that returns 9xx, and I hate it, but that’s the realworld. 😦

+24

quininer on Jan 10, 2020

https://tools.ietf.org/html/rfc7230#section-3.1.2:

status-code = 3DIGIT

https://tools.ietf.org/html/rfc7231#section-6:

The status-code element is a three-digit integer code … HTTP status codes are extensible.

https://tools.ietf.org/html/rfc7231#section-8.2.2 is only relevant if I want to register my status code to IANA, because https://tools.ietf.org/html/rfc7231#section-8 is “IANA Considerations”

A response with 3-digit status code >= 600 is syntactically(rfc7230) valid. This library, ideally, should leave the interpretation of the semantics(rfc7231) of a HTTP response to the code that uses it, especially since this library doesn’t try to enforce most of the semantics rules defined in rfc7231.

+11

eaufavor on Jul 31, 2020

In case anyone is interested, I’ve been using My own fork as a short term solution https://github.com/eaufavor/http/commit/fb16fac49816ad9e2f6286650ff0a614136226fe.

[patch.crates-io]
http = { path = "PATH_TO_REPO" }

eaufavor on Oct 19, 2020

What you mean is that we MUST follow the HTTP spec;
But what I am talking about is providing the ability to make user can define custom status code inside their business, as long as the participant in the communication know what they mean;

I think there are no conflict.

curl, openresty, wireshark … and so on, can parse the undefined status code and response phrase, why http and hyper have a limitation here.

kamyuentse on Nov 18, 2017

linkedin profiles return 999 when not logged in (I assume as a simple bot detection), browsers handle such responses without complaining.

inikulin on Oct 14, 2020

A status code of 6xx violates the HTTP spec.

Do you have an example of another server returning 6xx?

carllerche on Nov 17, 2017