Allow Content-Disposition header to be overridden per-field

`make_multipart` overrides the `Content-Disposition` header (see https://github.com/kennethreitz/requests/blob/54ad646067a3e023fd4dcf40c0937ec46069871f/requests/packages/urllib3/fields.py#L165), even when explicitly set (using the new per-field headers feature).

Is there any reason why the code couldn't be updated to allow this header to be explicitly set when providing files as 4-tuples containing the filename, content, content type and content disposition? The reason for wanting this feature is to allow working with REST APIs that do it all wrong (can't name names, sorry).


@orokusaki In principle there's no reason. I suggest raising the issue on urllib3 and seeing what @shazow thinks. =)


+1 on moving this discussion to urllib3, but a cursory comment: The tuple format is generally deprecated in urllib3 (only remains there as a shortcut, for now), constructing RequestField objects is the preferred way.


@shazow - interesting... is there currently a way to manually use a `RequestField` while using `request.post(...)`? If not, that would surely be something worth my contributing when I get a moment.

CC @Lukasa 


@orokusaki Yea, you should be able to pass a list of `RequestField` objects same way you pass a list of tuples. They should behave interchangeably. If that's not the case, please open a bug. :)

Might be worth updating the docs accordingly.


@shazow No docs changes on our side. =) There's no plan to officially document the crazy things you can do with multipart encoding because they make us sad. There's plans afoot to move some multipart stuff outside the main library, which will likely become the preferred way of doing anything non-trivial with multipart encoding.


@shazow - sorry to pester, but I'm not sure I follow. I normally use `post` like this:

```
requests.post(
    'http://www.example.com/',
    data={'field': 'value'},
    files=[('filename.txt', 'file content', 'text/plain', {'some-header': 'some value'})]
)
```

Where would manually creating a `RequestField` fit into that equation, simply replacing the list of `files` with a list of `RequestField` instances? If so, it would seem that the header would still be overwritten per https://github.com/kennethreitz/requests/blob/d88cd02fd86c6e74ef8a2d1928db78b8976ce00f/requests/models.py#L141 - also would result in a likely error due to the lines preceding that line, right?

I might simply be confused as to what you mean though.

CC @Lukasa 


TIL requests has its own code for this. I believe your understanding is correct, and that is indeed the case.

Soooo, the bug is back in requests land.


Ah, so it sounds like maybe a `requests==3.0.0` type of feature, if it were to be added. Thanks for checking on that for me @shazow.

@Lukasa @kennethreitz If more things were delegated to urllib3, it would simplify the requests codebase even more. If either of you have suggestions pertaining a change like this, I'd be more than happy to take a stab at it.


@orokusaki That's true, but not relevant. In our list of priorities, the simplicity of the API is vastly higher than the simplicity of the codebase. We're already not hugely happy with the interface here, and using `RequestField` classes is not going to make us happier.

As mentioned above, we're more likely to suggest that anyone who needs to do something interesting with multipart encoding use a third-party package that interoperates with Requests. Right now such a package doesn't exist, but there are plans to work on one.


You can just write your own class with it's own `__iter__` that does exactly what you wants. Very simple :)