Actions
Bug #15119
closedCivetweb responds with Content-Type with a 304 Not Modified response
Status:
Duplicate
Priority:
Normal
Assignee:
-
Target version:
-
% Done:
0%
Source:
other
Tags:
rgw,varnish,civetweb,rfc,http
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):
Description
When a conditional request is done towards RGW with Civetweb and the content is not modified it responds with a Content-Type header set to 'binary/octet-stream'.
For example, this is what I see coming back from Varnish:
- BerespProtocol HTTP/1.1 - BerespStatus 304 - BerespReason Not Modified - BerespHeader Bucket: cdn01 - BerespHeader x-amz-request-id: tx000000000000003bffeb1-0056e6d1eb-ca00be-ams02 - BerespHeader Content-type: binary/octet-stream - BerespHeader Content-Length: 0 - BerespHeader Date: Mon, 14 Mar 2016 14:59:55 GMT
Looking at RFC7232 I found this: https://tools.ietf.org/html/rfc7232#page-18
The server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.
This doesn't say that we have to respond with a Content-Type header.
IF we respond with a Content-Type header, we should at least respond with the proper mimetype.
I think these two headers should not be returned on a 304 Not Modified:
- Content-Type
- Content-Length
Updated by Wei-Chung Cheng about 8 years ago
- Related to Bug #14005: RGW shouldn't send Content-Type nor Content-Length for 304 responses added
Updated by Wei-Chung Cheng about 8 years ago
- Related to deleted (Bug #14005: RGW shouldn't send Content-Type nor Content-Length for 304 responses)
Updated by Wei-Chung Cheng about 8 years ago
- Is duplicate of Bug #14005: RGW shouldn't send Content-Type nor Content-Length for 304 responses added
Actions