Actions
Bug #439
closedDuplicate "Status" headers being sent
% Done:
0%
Source:
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):
Description
In my error_log I started seeing:
[Mon Sep 27 16:00:40 2010] [error] [client 2a00:f10:103:1::2810:1337] FastCGI: comm with server "/var/www/radosgw" aborted: error parsing headers: duplicate header 'Status'
I added some logging and saw:
RADOS S3 Gateway: auth_sign=OS09ZNIbpTLzqVBwNRSjYrIrhA4= RADOS S3 Gateway: compare=0 Status: 100 Status: 200 [Mon Sep 27 16:00:40 2010] [error] [client 2a00:f10:103:1::2810:1337] FastCGI: comm with server "/var/www/radosgw" aborted: error parsing headers: duplicate header 'Status'
When looking through the source I found that dump_continue() is called in rgw_main.cc, there it adds this header on every request, but should it?
I've been reading the RFC and saw: http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3
An origin server SHOULD NOT send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue" expectation, and MUST NOT send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility with RFC 2068, a server MAY send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header field with the "100- continue" expectation.
The 100-continue should imho only be sent whenever a client tries to upload a new file. It sends the headers, the RGW checks the credentials, and then response with the continue header, preventing the client from sending all the data and then finding out it wasn't permitted to do so.
Files
Actions