feat: add request limits on accept, content-type, and content-length headers

[stijnmoreels]

Adds request guards/limitation on:

• Accept header
• Content-Type header
• Content-Length header
  With user-friendly error http responses.

Closes #392

[stijnmoreels]

I tried to follow the style guidelines and way of working, please let me know if I did anything wrong. Happy to help! 👍

[TheAngryByrd]

Looks good from my end. I only have some questions that other maintainers (@dustinmoris) should weigh in on.

So far Giraffe doesn't have many error messages it returns that are hard coded. I could only find one place where we do it. I'm wary of having error messages like this hard coded for localization and even preference reasons. However I'm unsure of how to resolve this easily within this library.

[stijnmoreels]

Looks good from my end. I only have some questions that other maintainers (@dustinmoris) should weigh in on.

So far Giraffe doesn't have many error messages it returns that are hard coded. I could only find one place where we do it. I'm wary of having error messages like this hard coded for localization and even preference reasons. However I'm unsure of how to resolve this easily within this library.

Maybe we can have a different set of functions that takes in a custom error HTTP handler. There maybe needed two, as we check both on the presence of the header and whether the header has the correct value.

let haveContentTypesCustom contentTypes errorHandler = // ...

[dustinmoris]

I'd prefer to make the first parameter of each of these handlers to accept an error handler. It's not just about changing the message, but the entire response should be flexible. For example an API could return this as a JSON object or plain text response but a website might want to render a HTML page with the error displayed.

Here's an example of where this approach has already been taken:
https://github.com/giraffe-fsharp/Giraffe/blob/master/src/Giraffe/Negotiation.fs#L159

Of course in the final user application one would define that handler only once and then use the new handler for everything else, e.g.:

let someErrorHandler = ...

let validateContentType = haveAnyContentTypes someErrorHandler contentTypes

// then use validateContentType everywhere else

[stijnmoreels]

Ok, that's fine by me! 👍 I'll change this to your needs.
Although, in the negotiation example, the exception handling (unacceptable handler) is passed not as the first parameter.

[64J0]

This feature looks pretty cool!

[64J0]

I'll review this PR either this or next week.

[64J0]

I changed this branch's code to accept custom handlers from the user of this feature. And added more unit tests to validate these new scenarios.

This PR is adding some helper middlewares that will filter requests based on some header values. Do you think it makes sense to add it to Giraffe? I know that we have other helper middlewares as well, like:

• https://github.com/giraffe-fsharp/Giraffe/blob/master/src/Giraffe/Negotiation.fs#L159
• https://github.com/giraffe-fsharp/Giraffe/blob/master/src/Giraffe/ResponseCaching.fs

What do you think? Pinging especially @dbrattli and @nojaf to know their opinion.

[nojaf]

Sorry for the late review here. This slipped off my radar and I don't feel very qualified to say much about this. I don't use Giraffe that often and that makes it hard to have any opinion about the API.

I would merge this in and publish an alpha.
Ask people if the API works for them and take it from there.