Peter Rader opened SPR-17033 and commented
RFC2616 points out in page 31 the structure of HTTP messages:
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
As you can see, we have a CRLF at the end of each header and one additional CRLF to seperate body from header.
Assuming we have no body, the end of the HTTP message will end with the bytes
CR-LF CR-LF
What is the problem? We technically can not tell if a value is present and have a length of 0 bytes OR no body is posted what must be interpreted as null.
This is a problem if we have this construct:
@RequestMapping
public void test(@RequestBody(required=false) String httpBody) {
}
We have a special case here. The parameter httpBody is expected to contain the HTTP's [ message-body ] scope. In httpBody must contain all bytes right after the CR-LF CR-LF.
The effect of this problem is that if we post a empty string: the parameter httpBody must be a empty string and can never be null.
Vice versa for a (required=true): If we send a empty string, spring will decline the 100% correct request (having a empty string as body) as invalid because a empty string is interpreted as no-value where a value is required.
You could say: > Hey, lets check the header "Message-Length", it the header is present and the length is 0, it is a empty string and if no "Message-Length" is sent, its a null-value.
This is a good solution .... but: This does not work for security reasons in browsers. In browsers are commonly used the XMLHttpRequest-Object. The XMLHttpRequest is not allowed to set the Content-Length header-field.
My suggestion:
Let us introduce a specific header (respectievly the RFC6648 against x-header-constructs) to evaluate if the message-body should be interpreted as an empty string or null.
Affects: 5.0.7
Reference URL: https://tools.ietf.org/html/rfc2616#page-31
Comment From: bclozel
We don't plan to address this subtle nullability-detection behavior in Spring web frameworks.