Project

General

Profile

Actions

Bug #439

closed

Duplicate "Status" headers being sent

Added by Wido den Hollander over 13 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
% 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

Also available in: Atom PDF