`Content-Disposition` in subpart header includes `filename` for non-file multipart fields

The `files` parameter can be used to submit multipart form data.  I'm not certain whether `files` is a misnomer (since multipart form data doesn't necessary) or whether the implementation purposefully limits itself to supporting files as multipart data.  However, there are valid use cases for multipart forms where some of the fields are not files.

Take for example an API that allows you to POST a file along with a description of that file:

``` python
>>> url = 'http://httpbin.org/post'
>>> files = {
    'file': open('report.xls', 'rb'),
    'description': 'The PKIs that will drive synergy for the quarterly social'
                   'media campaign in the cloud.'
}
>>> r = requests.post(url, files=files)
```

In this case, the `description` field is not being used for file data.

The problem is that this field is nevertheless treated as being file data, as `filename` is added to `Content-Disposition` header of the subpart, defaulting to the value of `name` (or using `file.name` if available.)

`urllib3` supports subparts that don't have file names (in `urllib3.filepost.encode_multipart_formdata`), and appropriately omits the `filename` parameter:

``` python
def encode_multipart_formdata(fields, boundary=None):
    # ...
    for fieldname, value in iter_fields(fields):
        # ...
        if isinstance(value, tuple):
            filename, data = value
            writer(body).write('Content-Disposition: form-data; name="%s"; '
                               'filename="%s"\r\n' % (fieldname, filename))
            body.write(b('Content-Type: %s\r\n\r\n' %
                       (get_content_type(filename))))
        else:
            data = value
            writer(body).write('Content-Disposition: form-data; name="%s"\r\n'
                               % (fieldname))
            body.write(b'Content-Type: text/plain\r\n\r\n')
```

However, `isinstance(value, tuple)` in this function is always true, courtesy of this code in the library:

``` python
class Request(object):
    # ...
    def _encode_files(self, files):
        # ...
        for (k, v) in list(files.items()):
            # support for explicit filename
            if isinstance(v, (tuple, list)):
                fn, fp = v
            else:
                fn = guess_filename(v) or k
                fp = v
            if isinstance(fp, (bytes, str)):
                fp = StringIO(fp)
            fields.update({k: (fn, fp.read())})

        (body, content_type) = encode_multipart_formdata(fields)

        return (body, content_type)
```

I'd like to suggest that if no filename is provided (and it can't be read from `file.name`), the default behavior is to not include the `filename` parameter in the `Content-Disposition` subpart header.  This is simply a matter of not passing `encode_multipart_formdata` a filename for a given field if one is not provided in the `Request.files` parameter (instead of providing a default, as is now done.)

I'm posting this because a service I'm interfacing with changes its behavior if the `filename` is provided for a non-file field.  After reading through RFC 2388, I determined that the right place to fix this is probably in `requests` instead of the original library.  I can elaborate if necessary.


You can specify a blank filename if you'd like.


Also, you can pass both a `data` and `files` parameter, and they will be merged appropriately. 


Yes, that suits my purposes quite nicely.  My problem is that even when I specify a blank filename, the `filename` parameter is still passed into `Content-Disposition`, changing the semantics of the field as well as behavior in some services.

This appears to be a simple bug, because the urllib3 multipart encoding function offers the possibility to omit the `filename` parameter in `Content-Disposition` by not specifying a filename (by not passing a tuple), but `Request._encode_files` always sets a filename and passes in a tuple to urllib3 in all cases, so that execution path is never run.


I'm not sure what went through my head when you said I could use the `data` and `files` parameters and that they would be merged, but that is doing absolutely the same thing as the patch I'm proposing.

It is also without the drawback of requiring the developer to pass actual field data into `files` (which, as it has been clearly named to indicate, is meant for files.)

Poorly thought out. Sorry!