Test error paths

[mleonhard]

A web server needs tests for all kinds of bad behavior:

• Deviations from the HTTP protocol and its included formats (gzip, brotli, deflate, base64, etc).
• Pathological network behavior. Examples:
  • shutting down different sides of the stream at different points of the protocol
  • sending multiple requests without reading response or after reading a single byte of the response
  • sending 1 byte at a time
  • reading up to the middle of a response or chunk
• Resource exhaustion
  • Overlong headers
  • Headers spread over many lines
  • content-length too long
  • body length not matching content-length
  • over-long chunks
  • many single-byte chunks
• Deliberate attacks, excluding DDoS overload attacks. Examples:
  • hash collision DoS attack
  • header confusion attacks
  • overlong UTF-8

I looked around the code and couldn't find these. Is there something on the roadmap to add them?

[jbr]

This is a great set of questions, and likely a bunch of distinct issues for the http implementation. Some of these are supported, some are not.

I'll answer each of these to the best of my knowledge, but would be extremely interested to learn of any inaccuracies or provable bad behavior on the part of the http layer.

In general, if the http layer encounters something that does not conform to protocol, it will drop the tcp connection gracefully. Sometimes if it's possible, it will try to send a 500 error.

• Deviations from the HTTP protocol and its included formats (gzip, brotli, deflate, base64, etc).

Trillium currently treats compression as a distinct concern from the http implementation. [trillium-compression] currently only supports outbound compression, but when it adds inbound compression, it will likely be a fallible extension to ReceivedBody so application code can determine how to handle that error.

• Pathological network behavior. Examples:

  • shutting down different sides of the stream at different points of the protocol

I believe this is fully handled, and should be graceful in all circumstances

• sending multiple requests without reading response or after reading a single byte of the response

If the tcp connection is closed, we will not send any content. We will, however, finish running handlers.

• sending 1 byte at a time

There is not currently any explicit protection against this, and it's worth looking into the behavior. It might slow down other requests, but I don't think it would crash trillium or anything like that.

• reading up to the middle of a response or chunk

I believe this should be entirely fine

• Resource exhaustion

  • Overlong headers

Trillium currently support a fairly conservative maximum of 2kb of request headers and a maximum of 128 headers. When those are exceeded, we send a 500 and log a descriptive error. These should eventually be user-configurable, and I can prioritize that if it's important to anyone.

• Headers spread over many lines

The header parsing is currently handled by httparse, and I have every confidence this handles this behavior according to spec

• content-length too long

If the request content-length is longer than the provided bytes, I think trillium currently will return the available bytes. This probably should be an error, however.

• body length not matching content-length

If the body is longer than the content-length, we will read the content-length number of bytes, respond to the request, and treat the remaining bytes (buffered or not) as the start of a subsequent pipelined request.

• over-long chunks

If there is not a chunk boundary where it is expected, we will return an error in the handler code that is attempting to read the request body. Application code can determine how to handle this.

• many single-byte chunks

This may degrade performance but I do not think there is any further issue with it. We will read however many bytes that the networking stack has available for us, up to the number of bytes we have allocated to read. Many single byte chunks will result in slower throughput but no more allocation.

• Deliberate attacks, excluding DDoS overload attacks. Examples:

  • hash collision DoS attack

there are no hashmaps or hashsets in trillium's server implementation

• header confusion attacks

header parsing is handled by httparse

• overlong UTF-8

I'm not sure about this one, but we don't assume utf8 anywhere in library code, and application code will receive an Err variant if they attempt to read a request body that is not utf8 as a string.

I looked around the code and couldn't find these. Is there something on the roadmap to add them?

Could you clarify what you mean by add them? Do you mean a test suite for pathological requests? I'd love to have this, and looked around a lot for something like this when I was working on the http layer. In my opinion, there's no reason for this sort of "pathological http server test suite" to be tied to any particular server implementation. Ideally, there would be a cli tool that could be run against a port and that hammers the server with each of these malformed request types. I'd love to write that, but it's not a particularly high priority for me currently unless someone sponsors me to do it.

[mleonhard]

Yes, I think Trillium needs tests for all of these behaviors. Each test should start a Trilium server and communicate with it over TCP. Without these tests, I will be testing Trillium in production.

I started writing a library like Trillium some time ago, as I was learning Rust. Here is a test suite:
https://gitlab.com/leonhard-llc/beatrice-http-rs/-/blob/main/tests/integration_test.rs

Related: https://github.com/httpwg/wiki/wiki/HTTP-Testing-Resources

[jbr]

This is entirely reasonable, and seems exactly like the sort of work I would expect someone using trillium for a mission-critical commercial project to be willing to sponsor. As it stands, I encourage anyone using trillium for mission-critical commercial work that is unable to sponsor the project to run trillium behind a reverse proxy.

[jbr]

That said, there are currently zero known bugs in the http implementation, and fixing any bugs that were reported would be the highest priority, especially any bugs with security considerations. If you encounter any protocol bugs, please report them and I will have a patch fix within 48h in the worst case, and likely a lot faster than that. I think that's probably a better SLA than you'll find for any other free open source product.

[mleonhard]

Related: https://github.com/hyperium/hyper/blob/master/tests/server.rs