requests unexpectedly decode gzip content in some case

I'm attempting to retrieve https://donneespubliques.meteofrance.fr/donnees_libres/Txt/Synop/Archive/synop.201803.csv.gz using python requests.

However, when accessing response's content I get the csv data, not the gzipped-csv data like I would have expected. 

## Actual Result

    >>> url
    'https://donneespubliques.meteofrance.fr/donnees_libres/Txt/Synop/Archive/synop.201803.csv.gz'
    >>> resp = requests.get(url)
    >>> resp.headers
    {'Date': 'Thu, 19 Apr 2018 10:48:11 GMT', 'Server': 'MFWS', 
     'Last-Modified': 'Sat, 31 Mar 2018 21:10:09 GMT', 
     'ETag': '"3066bd-a2dce-568bbc81bee40"', 
     'Accept-Ranges': 'bytes', 
     'Content-Length': '667086', 
     'Content-Type': 'application/x-gzip', 
     'Content-Encoding': 'gzip',
     'Content-Disposition': 'attachment', 
     'Keep-Alive': 'timeout=5, max=300',
     'Connection': 'Keep-Alive'}
    >>> resp.content[:30]
    b'numer_sta;date;pmer;tend;cod_t'
    >>> requests.__version__
    '2.18.4'

## Expected Result

I would have expected to get the gzip file, consistently with the 'Content-Type' header.

If I access the same URL with e.g. curl I get the gzipped content as expected:

    $ curl https://donneespubliques.meteofrance.fr/donnees_libres/Txt/Synop/Archive/synop.201803.csv.gz  -s > data
    $ file data
    data: gzip compressed data, was "synop.201803.csv", last modified: Sat Mar 31 21:10:08 2018, from Unix

Same thing with direct use of urllib3:

    >>> http = urllib3.PoolManager()
    >>> resp = http.request('GET', 'https://donneespubliques.meteofrance.fr/donnees_libres/Txt/Synop/Archive/synop.201804.csv.gz')
    >>> resp.data[:30]
    b'\x1f\x8b\x08\x081\x86\xe7Z\x00\x03synop.201804.csv\x00\xcc\xfd\xd9'

Is this a requests feature I don't get? A server misconfiguration?


## System Information

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.5rc1"
  },
  "platform": {
    "release": "4.16.0-1-amd64",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "1010008f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}
```


The server specified the content encoding and we pass `decode_content` to urllib3. This checks the content encoding and decodes it for you. 

You can disable this by passing stream=True to requests. However it seems that the server doesn’t want the file decoded on the client side natively so maybe this is also server misconfiguration

sorry if I'm missing something, but how come I don't get the same behaviour
when using urllib3 directly?

I also thought it was a server misconfiguration at first, but digged deeper
since curl and wget were working as expected.


As I said, we pass decode_content=True which you are not passing

Digging a bit deeper...

urllib3's decode_content doesn't seem to be the explanation, as it's True by default. 

This seems rather due to difference with the 'Accept-encoding' setting: if 'gzip' is specified as accepted encoding, then the server send back a 'Content-encoding=gzip' , if not it's sending 'Content-encocindg=x-gzip'::

    syt@volt:/tmp$ curl https://donneespubliques.meteofrance.fr/donnees_libres/Txt/Synop/Archive/synop.201804.csv.gz --compressed -s > test_data
    syt@volt:/tmp$ file test_data
    test_data: ASCII text, with very long lines
    syt@volt:/tmp$ curl https://donneespubliques.meteofrance.fr/donnees_libres/Txt/Synop/Archive/synop.201804.csv.gz -s > test_data
    syt@volt:/tmp$ file test_data
    test_data: gzip compressed data, was "synop.201804.csv", last modified: Mon Apr 30 21:10:09 2018, from Unix, original size 3387471


So in my example I guess raw urllib3 doesn't send Accept-encoding, while requests does. In the former case, content isn't decoded because 'x-gzip' encoding is not known, while it is in the former since 'gzip' is.

It definitly looks like a weird server configuration...

@sigmavirus24 thank you for looking a this and sorry for wasting your time