You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 6, 2023. It is now read-only.
The optional gzip compression for requests and responses is introduced with #40 PR.
During the implementation, an interesting Riak compression-related behaviour was found: if a value was stored using gzipped request, then all subsequent 'fetch-value' requests are served with gzipped responses (no matter if requests don't specify an Accept-Encoding header).
Moreover, if a subsequent 'fetch-value' request does specify an Accept-Encoding: identity header (which is supposed to force a no-encoding option), Riak responds with a HTTP 406 Not Acceptable error. o_O
So, "if a value has been stored with a gzipped request, one should not dare to read it without compression support". <- "👍"
How to reproduce
# Prepare a simple test gzipped payload
> echo “bar" | gzip > bar.gz
# Store a value with a compressed request
> curl -XPUT --data-binary @bar.gz -H "Content-Encoding: gzip" http://127.0.0.1:8098/buckets/test-client-compression-support/keys/foo
# Fetch a value with no `Accept-Encoding` header: response will be gzipped!
> curl -v http://127.0.0.1:8098/buckets/test-client-compression-support/keys/foo
… Content-Encoding: gzip …
# Try to fetch a value with a forced “no encoding” (i.e `Accept-Encoding: identity` header): a 406 Not Acceptable error is returned!
> curl -H "Accept-Encoding: identity" http://127.0.0.1:8098/buckets/test-client-compression-support/keys/foo
<html><head><title>406 Not Acceptable</title></head><body><h1>Not Acceptable</h1>Not Acceptable<p><hr><address>mochiweb+webmachine web server</address></body></html>
This scenario is reproducible with eleveldb and memory backends, with Riak 1.4.10 and 2.1.1 versions.
Workaround
As a workaround, Riak response headers (both for normal AND multipart responses) are always inspected and payload is decoded if necessary (whether gzip encoding was requested or not).
This workaround is tested with RiakGzipSpec specs.
The text was updated successfully, but these errors were encountered:
Problem
The optional gzip compression for requests and responses is introduced with #40 PR.
During the implementation, an interesting Riak compression-related behaviour was found: if a value was stored using gzipped request, then all subsequent 'fetch-value' requests are served with gzipped responses (no matter if requests don't specify an
Accept-Encoding
header).Moreover, if a subsequent 'fetch-value' request does specify an
Accept-Encoding: identity
header (which is supposed to force ano-encoding
option), Riak responds with aHTTP 406 Not Acceptable
error. o_OSo, "if a value has been stored with a gzipped request, one should not dare to read it without compression support". <- "👍"
How to reproduce
This scenario is reproducible with eleveldb and memory backends, with Riak 1.4.10 and 2.1.1 versions.
Workaround
As a workaround, Riak response headers (both for normal AND multipart responses) are always inspected and payload is decoded if necessary (whether gzip encoding was requested or not).
This workaround is tested with
RiakGzipSpec
specs.The text was updated successfully, but these errors were encountered: