Handle GET, HEAD, and OPTIONS correctly in ContentLengthLimit

[davidpdrsn]

Motivation

ContentLengthLimit is normally applied to a single handler as a regular extractor. However nothing prevents the user from doing .layer(from_extractor::<ContentLengthLimit<(),1024>>()) to limit the size of payloads to all handlers. This doesn't work though since browsers don't send a content-length header on GET requests causing ContentLengthLimit to reject the request.

Solution

Change ContentLengthLimit to accept GET, HEAD, and OPTIONS requests that don't have a content-length header.

We discussed this a bit in Discord and landed on rejecting GET, HEAD, and OPTIONS requests that have a content-length.

We also agreed on not changing the body to an empty body.

I'd categorize this as a bug fix but I could see some making the argument that its a breaking change. Let me know what you think.

cc @neoeinstein

[jplatte]

What will hyper do to requests with one of these methods that do have a body? Could this create an additional attack surface in practice?

[davidpdrsn]

Hyper is fine with GET requests with bodies.

[jplatte]

Oh but it stops reading after content-length bytes are reached, or doesn't read the body at all if there is no content-length?

[davidpdrsn]

If there is a content-length it stops reading after the length, if there is no content-length (and no chunked encoding) it doesn't read the body and it appears empty to the user.

[neoeinstein]

The body is assumed to be empty if there is no Transfer-Encoding or Content-Length header. If there is a Content-Length header, hyper will stop reading once Content-Length bytes have been read.

The one hole here that we may want to close: If a GET, HEAD, or OPTIONS doesn't have a Content-Length header, but does have a Transfer-Encoding header, then this extractor should reject the request (same as if missing the Content-Length header). That will prevent a body being smuggled into a GET/HEAD/OPTIONS request where we can't verify the length limit.

[davidpdrsn]

I'll fix that!

[davidpdrsn]

@neoeinstein I believe 711cc3e should do it!

[neoeinstein]

One typo change and a pattern-matching improvement.