Bug #12830
closedS3 PUT Object returns 411 Length Required after upgrading to 0.94.3
0%
Description
rgw 0.94.3, nginx 1.8.0, RHEL 6.6.
After upgrading from 0.94.2, S3 PUT Object operations return 411 Length Required. It seems that https://github.com/ceph/ceph/pull/4436 breaks FastCGI uploads through web servers that send both HTTP_CONTENT_LENGTH and CONTENT_LENGTH, unless the "make it work" option rgw content length compat is set to true. Since the runtime overhead of the extra test is minimal, and in fact is nonexistent in the "well-behaved" case that only one of HTTP_CONTENT_LENGTH and CONTENT_LENGTH is set, shouldn't the "compat" behavior be enabled unconditionally?
Updated by Jan Harkes over 8 years ago
In fact, I think Yehuda's first comment on the original PR hit the nail on the head. "Why not just take precedence of HTTP_CONTENT_LENGTH over CONTENT_LENGTH". As far as the broken web server argument, they are unlikely to randomly switch between broken and working requests so a simple override configuration setting would be sufficient.
Something like,
const char* http_content_length = info.env->get("HTTP_CONTENT_LENGTH");
/* The FastCGI standard says we must use HTTP_CONTENT_LENGTH. If it isn't set
* we fall back on CONTENT_LENGTH. The rgw content_length_compat config option
* can be set to force the fallback path in case the web server hands out broken
* HTTP_CONTENT_LENGTH values */
if (http_content_length && *http_content_length && !s->cct->conf->rgw_content_length_compat) {
s->length = http_content_length;
} else {
s->length = info.env->get("CONTENT_LENGTH");
}