don't write "Transfer-Encoding: chunked" when Content-Length is set

this commit fixes #1648


This looks fine to me. You could potentially just use `if` instead of `elif` here: might be slightly cleaner. @sigmavirus24, thoughts?


I'm so -1 on this and the issue that I can't even begin to explain. We have always maintained that sending your own `Content-Length` header was a bad idea and should never be done. It causes far more issues than it ever solves. If people are using generators I'd rather never send their custom `Content-Length` header. Regardless, if they're insistent upon using both together they should not expect random and entirely arbitrary behaviour on their part

To reiterate: If we're going to "fix" this, I vote that we just always, unconditionally, delete the `Content-Length` header set by the user no matter what. If we're going to hold the hands of our users we shouldn't allow them to do things we know are wrong or are going to break things.


@sigmavirus24 How would you handle the use case in the issue then (you want to use generators, but avoid chunked transfer encoding)? The Content-Length is valuable information, why should it be impossible to transmit? There is no way "requests" can know how much data the generator outputs. I suggest that "requests" throws an Exception if the generator generates less/more bytes than the specified Content-Length says. Of course, the data will already be sent by then, but at least the error will probably get discovered before production, and people will be aware of the fact that it needs to generate the right amount of bytes.


@ysangkok The use case in the issue is just an example of the behaviour. There is no justification there for why you're doing what you're doing. If you want to use a generator but don't want to send the `Transfer-Encoding` header I suggest you not special case and use magic behaviour to achieve what you want but instead use the features we already provide.

Don't just use the plain requests API, instead prepare a request yourself (which is now infinitely easier) and remove the header. If you want to set your own `Content-Length` header then it will already be there. Take greater advantage of the existing API.

Furthermore, requests doesn't count the bytes that you send, ever, unless it's determining the `Content-Length` header. If you're concerned about what you're sending and possibly sending too much you should probably be testing your code better. Tests would catch this for you, it isn't our responsibility.


I'd argue the other direction: I am actually sending a stream towards the HTTP server. This used to work just fine with an old version of requests. Sometime requests started adding a magic "Transfer-Encoding" header and dropping the known length information.
What's more it's not actually using chunked encoding but just pushes the stream through. After fixing that I found out that the server I am posting to refuses chunked transfer encoding when posting.

I would really like to be able to use session.post again for my simple use case. requests boasts in its README how easy it is to do simple things.


@Bluehorn you failed to provide us:
- Code to reproduce your issue
- The versions you tested
- A server to test against

Given you've provided us nothing to work with, we can't help you.


@sigmavirus24: I do not need help, I have a trivial patch that makes requests use the Content-Length again. After our code base works with the current requests for a while we will probably just do what you suggested:

> Don't just use the plain requests API, instead prepare a request yourself (which is now infinitely easier) and remove the header

I just liked the approach that the caller can set the headers without having requests overwrite/delete them better.