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…
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.
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.