Question

Given this snippet:

(defroutes main-routes
    (POST "/input/:controller" request
        (let [buff (ByteArrayOutputStream.)]
            (copy (request :body) buff) 
            ;; --- snip

The value of buff will be a non-empty byte array iff there’s the Content-Type header in the request. The value can be nonsencial, the header just has to be there.

However, I need to dump the body (hm… that came out wrong) if the request came without a content type, so that the client can track down the offending upload. (The uploading software is not under my control and its maintainers won’t provide anything extra in the headers.)

Thank you for any ideas on how to solve or work around this!

EDIT:

Here are the headers I get from the client:

{
   "content-length" "159",
   "accept" "*/*",
   "host" (snip),
   "user-agent" (snip)
}

Plus, I discovered that Ring, using an instance of Java’s ServletRequest, fills in the content type with the standard default, x-www-form-urlencoded. I’m now guessing that HTTPParser, which supplies the body through HTTPParser#Input, can’t parse it correctly.

Answer 1

I face the same issue. It’s definitely one of the middleware not being able to parse the body correctly and transforming :body. The main issue is that the Content-Type suggest the body should be parsable.

Using ngrep, I found out how curl confuses the middleware. The following, while intuitive (or rather sexy) on the command line sends a wrong Content-Type which confuses the middleware:

curl -nd "Unknown error" http://localhost:3000/event/error                                                                            

T 127.0.0.1:44440 -> 127.0.0.1:3000 [AP]
POST /event/error HTTP/1.1.
Authorization: Basic SzM5Mjg6ODc2NXJkZmdoam5idmNkOQ==.
User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3.
Host: localhost:3000.
Accept: */*.
Content-Length: 13.
Content-Type: application/x-www-form-urlencoded.
.
Unknown error

The following however forces the Content-Type to being opaque and the middleware will not interfere with the :body.

curl -nd "Unknown error" -H "Content-Type: application/data" http://localhost:3000/event/error                                        

T 127.0.0.1:44441 -> 127.0.0.1:3000 [AP]
POST /event/error HTTP/1.1.
Authorization: Basic SzM5Mjg6ODc2NXJkZmdoam5idmNkOQ==.
User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3.
Host: localhost:3000.
Accept: */*.
Content-Type: application/data.
Content-Length: 13.
.
Unknown error

I’m considering replacing the middleware with a more liberal one because even though the request is wrong, I’d still like to be able to decide what to do with the body myself. It’s a really weird choice to zero the request body when the request doesn’t make sense. I actually think a more correct behavior would be to pass it to an error handler which by default would return a 400 Bad Request or 406 Not Acceptable.

Any thoughts on that? In my case I might propose a patch to Compojure.