Support custom status code

[kamyuentse]

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.

[carllerche]

A status code of 6xx violates the HTTP spec.

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

[kamyuentse]

I know that neither HTTP spec nor IANA defines the status code greater than 599.

As I mentioned above, some RESTful service may use UNREGISTERED status codes.

The following is an example which uses openresty as backend server:

curl -v http://uc.qbox.me/v2/query\?ak\=INVALID_KEY\&bucket\=INVALID_BUCKET

Not support custom status codes and response phrase will stumble those want to migrate to rust.

[steveklabnik]

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

New status codes are required to fall under one of the categories defined

in Section 6 <https://tools.ietf.org/html/rfc7231#section-6>.

[kamyuentse]

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

[carllerche]

By sticking with the spec, the http crate is able to make performance optimizations. Violating the spec in this way would make the crate slower for those who follown then spec.

The argument to make the library slower for everyone would need to be very compelling.

[quininer]

Can we provide a feature gate for it?

[carllerche]

@quininer can you provide the use case?

[quininer]

@carllerche I have an interface that returns 9xx, and I hate it, but that's the realworld. :(

[nooberfsh]

@carllerche there are many services in qiniu return code > 600

[eaufavor]

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.

[inikulin]

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

[inikulin]

@carllerche

Also, considering that there is an ongoing work on PoC for integration with curl (which handles such codes without an issue), it makes sense to support what all the major UAs support.

In addition, as was pointed above, such codes don't violate RFC7231.

[inikulin]

As an additional argument, this crate supports arbitrary HTTP methods to which similar IANA considerations apply - https://tools.ietf.org/html/rfc7231#section-8.1. So, the spec argument is at least inconsistent.

[UmanShahzad]

Can this be given a second look? It indeed doesn't seem reasonable to restrict the range like this when the existing range is really just IANA specific and not binding on implementations, as long as they meet the syntax requirement and minimum semantic requirements.

[eaufavor]

In case anyone is interested, I've been using My own fork as a short term solution eaufavor@fb16fac.

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

[dekellum]

To try an give some more perspective on this, note that all of the following broadly used reverse proxy servers currently support status codes 100-999:

• haproxy
• varnish
• nginx

On one hand, it seems reasonable enough for a new server, like linkerd, to reject status codes >599. But particularly when the http crate is used as part of an HTTP client interface, it seems unnecessarily prescriptive for it to hard-error on responses with such status codes. Better to let the application handle it.