func tests must not assert accept-ranges on 304
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| OpenStack Object Storage (swift) |
Confirmed
|
Low
|
Unassigned | ||
Bug Description
Direct to swift request:
ubuntu@
* Trying 192.168.8.8...
* Connected to 192.168.8.8 (192.168.8.8) port 8081 (#0)
> GET /v1/AUTH_
> Host: 192.168.8.8:8081
> User-Agent: curl/7.47.0
> Accept: */*
> x-auth-token: gAAAAABYsLZmr8f
> if-none-match: d41d8cd98f00b20
>
< HTTP/1.1 304 Not Modified
< Content-Length: 0
< Content-Type: application/
< Accept-Ranges: bytes
< Last-Modified: Fri, 24 Feb 2017 18:22:10 GMT
< Etag: d41d8cd98f00b20
< X-Timestamp: 1487960529.71427
< X-Object-
< X-Trans-Id: tx12d4acd8de484
< X-Openstack-
< Date: Fri, 24 Feb 2017 22:41:26 GMT
<
* Connection #0 to host 192.168.8.8 left intact
Request behind Apache:
ubuntu@
* Trying 192.168.8.8...
* Connected to 192.168.8.8 (192.168.8.8) port 8080 (#0)
* found 176 certificates in /etc/ssl/
* found 704 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: localhost (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: O=OpenStack,
* start date: Fri, 24 Feb 2017 15:43:39 GMT
* expire date: Sat, 24 Feb 2018 15:43:39 GMT
* issuer: O=OpenStack,
* compression: NULL
* ALPN, server accepted to use http/1.1
> GET /v1/AUTH_
> Host: 192.168.8.8:8080
> User-Agent: curl/7.47.0
> Accept: */*
> x-auth-token: gAAAAABYsLZmr8f
> if-none-match: d41d8cd98f00b20
>
< HTTP/1.1 304 Not Modified
< Date: Fri, 24 Feb 2017 22:41:49 GMT
< Server: Apache/2.4.18 (Ubuntu)
< Connection: close
< Etag: d41d8cd98f00b20
<
* Closing connection 0
You can not assert the < Accept-Ranges: bytes header in this response in a functional test.
Mostly added in https:/
| Tim Burke (1-tim-z) wrote | #1 |
| Changed in swift: | |
| status: | New → Confirmed |
| importance: | Undecided → Low |
| tags: | added: low-hanging-fruit |
New RFC [1] definitely advises against it:
> Since the goal of a 304 response is to minimize information transfer
> when the recipient already has one or more cached representations, a
> sender SHOULD NOT generate representation metadata other than
> [Cache-Control, Content-Location, Date, ETag, Expires, and Vary]
> unless said metadata exists for the purpose of guiding cache updates
> (e.g., Last-Modified might be useful if the response does not have
> an ETag field).
Old RFC [2] even specified conditions where such headers MUST NOT be sent:
> If the conditional GET used a strong cache validator (see section
> 13.3.3), the response SHOULD NOT include other entity-headers.
> Otherwise (i.e., the conditional GET used a weak validator), the
> response MUST NOT include other entity-headers; this prevents
> inconsistencies between cached entity-bodies and updated headers.
Maybe we should ensure we *don't* send Accept-Ranges? Or, for that matter, Content-Type or X-Object-Meta-*. I'm rather annoyed with Apache for dropping the transaction ID though :-(
Note that there seem to be other circumstances in which Apache messes with our headers [3]...
[1] https:/
[2] https:/
[3] https:/