GET request with empty body and Content-Type of application/json fails after upgrading from 2.5 to 2.6


I am in the process of upgrading an application from 2.5 to 2.6.12. Some of our api requests are failing and I have tracked it down to the presence of a “Content-Type: application/json” header on a GET request with an empty body. The body of the response contains:

“message”: “Invalid Json: No content to map due to end-of-input\n at [Source: akka.util.ByteIterator$ByteArrayIterator$$anon$1@2c879642; line: 1, column: 0]”

This didn’t happen with 2.5 so I’m assuming that this is to do with the shift to Akka http. I know that technically the request should not have the content-type header, as there is no body, but it’s common for clients to include it on api requests and I was wondering if there is any way to relax this check?

Well… This messages comes from play, but I tried it to reproduce it, however on my machine it works.
On a POST request this message should appear. However not on a GET since the Body should be ignored.

However the behavior did not change much between 2.5 and 2.6

on 2.6:

curl -XGET -H 'Content-Type: application/json' -vvvv http://localhost:9000
Note: Unnecessary use of -X or --request, GET is already inferred.
* Rebuilt URL to: http://localhost:9000/
*   Trying ::1...
* Connected to localhost (::1) port 9000 (#0)
> GET / HTTP/1.1
> Host: localhost:9000
> User-Agent: curl/7.54.0
> Accept: */*
> Content-Type: application/json
< HTTP/1.1 200 OK
< Date: Wed, 28 Mar 2018 18:38:47 GMT
< Content-Length: 0
* Connection #0 to host localhost left intact

Did you define any body parser?

1 Like

Ahh, yes. That’s the problem. This request is going through a specialised Action instance. In converting to Play 2.6 ActionBuilder now takes another type parameter of the body type (which is AnyContent) and requires a default body parser to be declared in the implementation. I had chosen PlayBodyParsers.anyContent which tries to guess the type based on the Content-Type header. If I use PlayBodyParsers.default instead then it won’t try to decode an empty body.

1 Like

Technically the request @schmitch sent actually has no body. If the request had included a Content-Length: 0 header, that would be an empty body. I’m assuming the case you’re talking about is a GET with no body, which is the most common case.

I actually think it’s a little strange that the anyContent body parser tries to parse the body rather than returning an informative error in this case. That might be a good improvement we could make for usability.