Closed jconti closed 6 years ago
The SPEC can't be changed without breaking compatibility, since existing handlers expect that the body of the request is an InputStream
if present.
However, this is something I plan to address in Ring 2.0. My current thinking is that the body of the request should satisfy certain protocols, depending on whether the request is synchronous or asynchronous.
That sounds like a useful idea for 2.0. Thanks for sharing your thoughts and possible directions.
Routes that use
wrap-params
fail if a call to thering.util.request/body-string
multimethod have replaced a request's body stream with a string. This is a bug in my code, because the ring SPEC clearly states that the type of the :body key's value is java.io.InputStream (probably straight from the servlet API). So by usingring.util.request/body-string
my code is breaking that explicit contract for the request map, which causeswrap-params
to fail inring.middleware.params/assoc-form-params
.However it seems that the ability of a route to return nil so another route can attempt processing the request is problematic unless the request map is immutable. The body's stream prevents that immutability from existing. On some requests, of course, the stream must be retained and only processed once. However, others can be converted to strings.
So I have made it the habit (maybe erroneously) to apply this multimethod to the request very early in the processing of my routes, since all my input is forcefully limited in size. Unfortunately it breaks
wrap-params
. Ifwrap-params
used the samebody-string
multimethod however, instead of slurp, it would work fine.To do this I assume the SPEC would need to change the value of :body to be something compatible with the definition of ``body-string```. Maybe a protocol?