Skip to content

A better Server Error experience #1128

Closed
@seanmonstar

Description

@seanmonstar

There are 4 error cases on the server side:

  • When receiving/parsing the headers of a new incoming Request
  • When receiving/parsing the body of an established Request
  • When a Service's Future resolves to an Err, meaning that it just could not respond to the Request
  • When a user-supplied Stream has an error while generating more of the outgoing body

The current design requires that all 4 of these cases be covered by hyper::Error, but that type is not satisfactory for the semantics of each case. This design is currently required because of tokio-proto's ServerProto only allowing a single Error type. Relevant tokio issue: tokio-rs/tokio-proto#157

Another quirk with the current type is that users must return a hyper::Error when they encounter an error during their Service.call. This causes them to wonder which variant of the current hyper::Error they should use, when the real anwer is: none! They should be returning (if it was a server error) a response with a 5XX status code.

They are also asked to return a hyper::Error in the outgoing Stream, but that is also incorrect. No hyper error occurred! However, they cannot alter to sending a 500 response anymore, so the only valid thing to do is send an error type with the semantics of "something blew up, we cannot respond more, just abort the socket".

So, there are 2 error types that would better suit these 4 cases:

  • Error: The hyper::Error type that comes only from within hyper, and represents when there was an error trying to read and parse incoming HTTP data.
  • Disconnect: A type that comes only from the user, given to hyper, and represents that the connection should be terminated immediately. Other names could be Fatal, Close, Abort...

This separation would hopefully give more clarity as to what error a user should be returning, and that in the Service::Future type, they shouldn't returning an error at all, since the error name should be ominous enough to point at returning a response instead.

There is of course still desire for users to have streams that return error types of std::io::Error, such as streaming from a File, or even hyper::Error, when streaming from a proxied client request, so there should exist From implementations for those types.


New proposal: #1431

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-errorArea: error handling

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions