It seems that the observed behavior is a result of sending PUT requests
without specifying Content-Length HTTP header. RFC 7230 states that
the header should be applied [1]:
"3.3.2. Content-Length
(...)
A user agent SHOULD send a Content-Length in a request message when
no Transfer-Encoding is sent and the request method defines a meaning
for an enclosed payload body. For example, a Content-Length header
field is normally sent in a POST request even when the value is 0
(indicating an empty payload body)."
Most likely the improper requests have not been even delivered to radosgw
instance, but rejected by intermediary Apache server that is used as a FastCGI
front-end to radosgw. We already saw similar behavior in #1505273.
You may enforce curl to generate Content-Length for a request with empty
body through appending "-d ''" or "-H 'Content-Length: 0" to the argument list.
It seems that the observed behavior is a result of sending PUT requests
without specifying Content-Length HTTP header. RFC 7230 states that
the header should be applied [1]:
"3.3.2. Content-Length
(...)
A user agent SHOULD send a Content-Length in a request message when
no Transfer-Encoding is sent and the request method defines a meaning
for an enclosed payload body. For example, a Content-Length header
field is normally sent in a POST request even when the value is 0
(indicating an empty payload body)."
Most likely the improper requests have not been even delivered to radosgw
instance, but rejected by intermediary Apache server that is used as a FastCGI
front-end to radosgw. We already saw similar behavior in #1505273.
You may enforce curl to generate Content-Length for a request with empty
body through appending "-d ''" or "-H 'Content-Length: 0" to the argument list.
[1] https:/ /tools. ietf.org/ html/rfc7230# page-30 /bugs.launchpad .net/mos/ +bug/1505273
[2] https:/