A GET request with request body results in a 400/bad request, while
- HTTP in principle allows request bodies for GET requests
- ... but according to the lastest HTTP standard, "A payload within a GET request message has no defined semantics"
- the servant API is entirely permissive without warning regarding request bodies for GET requests
There are good arguments for prohibiting request bodies in GET bodies, as this would conform to the HTTP standard. The only problem: servant API does allow them and the current situation breaks the compile-time validation of the API.
Allowing request bodies in GET bodies doesn't strictly violate HTTP standards, by the way. One could consider it an abuse of the protocol though.
So either of these would be preferable to the current situation:
- allowing request bodies in GET requests and restoring compile-time safety of the API
- producing a meaningful error (preferably at compile time) whenever someone tries to use request bodies in GET requests, e.g. by adapting the
HasServer instance such that the ReqBody is ignored and a handler that expects the payload as argument doesn't typecheck
A GET request with request body results in a 400/bad request, while
There are good arguments for prohibiting request bodies in GET bodies, as this would conform to the HTTP standard. The only problem: servant API does allow them and the current situation breaks the compile-time validation of the API.
Allowing request bodies in GET bodies doesn't strictly violate HTTP standards, by the way. One could consider it an abuse of the protocol though.
So either of these would be preferable to the current situation:
HasServerinstance such that theReqBodyis ignored and a handler that expects the payload as argument doesn't typecheck