"Content-Type header: application/x-www-form-urlencoded" won't be overridden

Simple test under Python 3.3.2, using the current 2.0 branch of requests (same behaviour with requests-1.2.3 btw); inspecting request headers with requestb.in.
The Content-Type header contains two entries. I expected my stipulated header to override (replace) application/x-www-form-urlencoded.

import requests
data = open('C:/my_audio_files\sample_50.wav', 'rb').read()
response = requests.post(url = "http://requestb.in/183gv9g1"
                      data=data,
                      headers={'Content-Type': 'application/octet-stream'}
                      )

FORM/POST PARAMETERS

None
HEADERS

Content-Length: 38206
User-Agent: python-requests/1.2.3 CPython/3.3.2 Windows/8
Connection: close
Host: requestb.in
Content-Type: application/octet-stream, application/x-www-form-urlencoded
Accept: _/_
Accept-Encoding: identity, gzip, deflate, compress

RAW BODY

RIFF6WAVEfmt etc...


This is a known issue that was [just opened and closed](https://github.com/kennethreitz/requests/issues/1607). Please search in both closed and open issues next time before submitting a bug report.


This is not the same issue. @sebastien-bratieres claims that he observed this using the 2.0 branch of Requests. If that's the case, we still have a problem. =)


However, I don't observe this problem on the 2.0 branch:

``` python
>>> import requests
>>> import json
>>> r = requests.post('http://httpbin.org/post', data=json.dumps({'hi': 'there'}), headers={'Content-Type': 'application/json'})
>>> r.status_code
200
>>> print(r.text)
{
  "url": "http://httpbin.org/post",
  "form": {},
  "data": "{\"hi\": \"there\"}",
  "files": {},
  "origin": "192.91.191.29",
  "json": {
    "hi": "there"
  },
  "headers": {
    "User-Agent": "python-requests/1.2.3 CPython/3.3.0 Windows/7",
    "Accept-Encoding": "gzip, deflate, compress",
    "Accept": "*/*",
    "Content-Length": "15",
    "Connection": "close",
    "Content-Type": "application/json",
    "Host": "httpbin.org"
  },
  "args": {}
}
```

@sebastien-bratieres Can you attempt the exact same test I just did?

NB: Wireshark also shows correct behaviour.


Actually, this is particularly bizarre, as `application/x-www-form-urlencoded` shouldn't be applied to this _at all_. The data is a bytestring, so we should not apply a default content-type header.


Here are tests and their results on my system:

------------ your original test
import requests
import json
r = requests.post('http://httpbin.org/post', data=json.dumps({'hi': 'there'}), headers={'Content-Type': 'application/json'})
print(r.status_code)
print(r.text)

200
{
  "headers": {
    "Accept": "_/_",
    "User-Agent": "python-requests/1.2.3 CPython/3.3.2 Windows/8",
    "Accept-Encoding": "identity, gzip, deflate, compress",
    "Connection": "close",
    "Content-Type": "application/json",
    "Content-Length": "15",
    "Host": "httpbin.org"
  },
  "args": {},
  "files": {},
  "data": "{\"hi\": \"there\"}",
  "url": "http://httpbin.org/post",
  "form": {},
  "json": {
    "hi": "there"
  },
  "origin": "62.68.194.170"
}
------------ slight variant, works fine
import requests
data=json.dumps({'hi': 'there'})
response = requests.post(url = "http://httpbin.org/post",data=data,headers={'Content-Type': 'application/octet-stream'})
print(response.status_code)
print(response.text)

200
{
  "data": "{\"hi\": \"there\"}",
  "json": {
    "hi": "there"
  },
  "url": "http://httpbin.org/post",
  "files": {},
  "args": {},
  "origin": "62.68.194.170",
  "form": {},
  "headers": {
    "Accept": "_/_",
    "Accept-Encoding": "identity, gzip, deflate, compress",
    "Content-Type": "application/octet-stream",
    "User-Agent": "python-requests/1.2.3 CPython/3.3.2 Windows/8",
    "Host": "httpbin.org",
    "Connection": "close",
    "Content-Length": "15"
  }
}

------------ use a binary data file instead of json content
import requests
data = open('C:/text.txt', 'rb').read()
#data=json.dumps({'hi': 'there'})
response = requests.post(url = "http://httpbin.org/post",data=data,headers={'Content-Type': 'application/octet-stream'})
print(response.status_code)
print(response.text)

200
{
  "headers": {
    "Accept": "_/_",
    "User-Agent": "python-requests/1.2.3 CPython/3.3.2 Windows/8",
    "Accept-Encoding": "identity, gzip, deflate, compress",
    "Connection": "close",
    "Content-Type": "application/x-www-form-urlencoded, application/octet-stream",
    "Content-Length": "9",
    "Host": "httpbin.org"
  },
  "args": {},
  "files": {},
  "data": "hi there!",
  "url": "http://httpbin.org/post",
  "form": {},
  "json": null,
  "origin": "62.68.194.170"
}


@sebastien-bratieres Sorry, did you run that using the 2.0 branch? Because when I run the equivalent test using the 2.0 branch, I continue not to get duplicated headers.


To the best of my knowledge, yes... but doubting is in order as I'm just
starting to use git.
To make sure, I have removed my previous version of requests, obtained an
error on import, downloaded the github zip of branch 2.0 (
https://github.com/kennethreitz/requests/archive/2.0.zip ), ran setup.py
from there, and ran my tests again, with the same result. The install
directory is
c:\winpython-64bit-3.3.2.3\python-3.3.2.amd64\lib\site-packages\requests-1.2.3-py3.3.egg

I also ran this:

import requests
print(sys.version)
print(requests.**file**)

3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit
(AMD64)]
C:\WinPython-64bit-3.3.2.3\python-3.3.2.amd64\lib\site-packages\requests-1.2.3-py3.3.egg\requests__init__.py

Anything to do with the urllib version used in Python 3.3.2 ?

I'm not a confirmed Python user, so if there's any extra test I could run,
please let me know.

HTH
Sebastien

2013/9/18 Cory Benfield notifications@github.com

> @sebastien-bratieres https://github.com/sebastien-bratieres Sorry, did
> you run that using the 2.0 branch? Because when I run the equivalent test
> using the 2.0 branch, I continue not to get duplicated headers.
> 
> —
> Reply to this email directly or view it on GitHubhttps://github.com/kennethreitz/requests/issues/1608#issuecomment-24657611
> .


Yeah, that zip file is wildly out of date. It simply doesn't appear to have anything we've merged into that 2.0 branch in it. Very odd.

Try grabbing the git branch directly. If you have pip installed, you can use: `pip install https://github.com/facebook/python-sdk/zipball/master`. If not, clone the git repository and then check out the 2.0 branch before running `setup.py`. Let me know if you need help with that. =)


Yes, doing the proper git clone, obtaining branch 2.0, now rids me of the duplicate headers.

Apologies for the confusion and thanks for the help (now I can forget urllib and start using requests again !).
Sebastien


Not a problem at all, glad to be of help! Enjoy using Requests! :+1: