AhcWsRequest setting ContentType as application/octet-stream even if using EmptyBody

This behavior is implemented in the DefaultBodyWritables trait, extended by AhcWSRequest.

I am not sure whether this is just ok from a specification point of view, but this breaks interaction with a Spring-backed application that is receiving the request, as it fails if the body is empty and a content type is set.

Has anyone ever seen this issue? I can simply add an empty ContentType header, but it feels like this should be handled better in the DefaultBodyWritables


Hi @iaco86,

Well, RFC 7231 says this about the Content-Type header:

The “Content-Type” header field indicates the media type of the associated representation: either the representation enclosed in the message payload or the selected representation, as determined by the message semantics.

And a little later:

A sender that generates a message containing a payload body SHOULD generate a Content-Type header field in that message unless the intended media type of the enclosed representation is unknown to the sender. If a Content-Type header field is not present, the recipient MAY either assume a media type of “application/octet stream” ([RFC2046], Section 4.5.1) or examine the data to determine its type.

In other words, when there is a payload body, you should add a Content-Type, however, there is not a crystal clear section saying that you should not have Content-Type when the payload is empty.

Anyway, I think a small improvement we can do to the existing API is to define BodyWritable to have a contentType: Option[String] instead of contentType: String. That way, you can write a BodyWritable that does not sets the Content-Type header.

If you want to make that happen, https://github.com/playframework/play-ws is the place to go. :slight_smile:


Hey @marcospereira,
thanks for the pointers! I am in the process of getting the CLA approved, then hopefully I will be able to contribute to the project.

Your suggestion makes sense, and hopefully is going to help who encountered the same issue we faced in our system.


1 Like