accept-encoding should not default to gzip

[bahamat]

The SDK defaults to Accept-Encoding: gzip, but doesn't decompress the stream for consumers. This leaves them with a stream that they need to explicitly decompress, which is undocumented. The default behavior should be working with little to no extra effort. So the SDK needs to either decompress it automatically or default to no encoding.

The preference is to skip encoding. If consumers want to encode, they can pass the header explicitly and handle decompression themselves.

[indianwhocodes]

@bahamat As I see from RFC-2616#14.3 we have two options here:

  1. If the content-coding is one of the content-codings listed in
     the Accept-Encoding field, then it is acceptable, unless it is
     accompanied by a value of 0. (As defined in section 3.9, a
     qvalue of 0 means "not acceptable.")

  2. The special "*" symbol in an Accept-Encoding field matches any
     available content-coding not explicitly listed in the header
     field.

  3. If multiple content-codings are acceptable, then the acceptable
     content-coding with the highest non-zero qvalue is preferred.

  4. The "identity" content-coding is always acceptable, unless
     specifically refused because the Accept-Encoding field includes
     "identity;q=0", or because the field includes "*;q=0" and does
     not explicitly include the "identity" content-coding. If the
     Accept-Encoding field-value is empty, then only the "identity"
     encoding is acceptable.

So we can either have the SDK set the default value to identity or *. I would prefer the latter. Thoughts ?

[indianwhocodes]

This issue can be resolved by adding a new line such as

new BasicHeader(HttpHeaders.ACCEPT_ENCODING, "*")

in MantaHttpRequestFactory.java at L45 and the update the API docs accordingly.