fixed type annotation
Merge pull request #151 from flying-sheep/patch-2

fixed type annotation
Add websocket subprotocol support

## Rationale:

We have to manually do this currently even while it should be part of the handshake.

This leads to ignorance of this feature, and chrome not working due to a missing header when testing only in firefox (which ignores if none of sent subprotocols come back)

## Implementation and usage:

I’m adding a kwarg to `do_handshake` which allows the user to specifiy subprotocols his/her client speaks. `do_handshake` returns an additional header with the chosen protocol if the handshake is successful. This doesn’t break the API in any way.

If the server speaks any of the supplied subprotocols, the first protocol spoken by both is selected from the the client-supplied list, else the handshake fails. Essentially this means that you order the `protocols` sequence by preference: best protocol first, worst last.

## Open Questions:

1. The agreed-upon protocol is valuable information not only for the Server, but the user: If we speak multiple protocols, we want to know which one the handshake selected. The user has to extract it from the headers, which are simply a sequence and no dict, making this impractical.

    Should we change the response tuple to include the protocol as fifth mamber? This would break unpacking assignments like this:

        ```python
        >>> code, response_headers, parser, writer = do_handshake('get', headers, transport)
        Traceback (most recent call last):
          File "<stdin>", line 1, in <module>
        ValueError: too many values to unpack (expected 4)
        ```

        We could also return something unpackable to 4 elemets that also has a “protocol” field, but that would make the code more complex (tuples are very useful to avoid creating Java-style result-classes).

2. Autobahn|Python forbids duplicate mentions of protocols in the comma-separated list sent by the server. Should we also fail the handshake when this happens or be more lenient?
added myself to contributors list
broke websocket API and added tests
Fix typo in docs.
Merge pull request #152 from AlexWC/patch-1

Fix typo in docs.
Send raw files as is

This fixes the behavior when on attempt to POST file object or BytesIO
aiohttp instead of sending their content as is wraps them with multipart
request what isn't welcome for most cases.

This commit changes that behavior: if you call aiohttp.request with
data parameter as file or BytesIO, it will send them as raw binary
chunked stream. In case of files, when Content-Type header isn't set
aiohttp will try to guess the mimetype using the mimetypes module.
Otherwise default 'application/octet-stream' will be used.

There are also checks for StringIO and files opened in text mode: both
aren't allowed since they may cause to send data using not the encoding
you expected to.
Merge pull request #153 from kxepal/upload-filelike-objects

Send raw files as is
Add PyCharm files in .gitignore
Add 307 handling (#155) + for 301 and 302, mimic IE behaviour, now changed in RFC. Details: https://github.com/kennethreitz/requests/pull/269
Merge pull request #157 from Eyepea/improve_redirect_handling

Improve redirect handling
Merge pull request #150 from flying-sheep/patch-1

Add websocket subprotocol support
update websocket examples
update changelog
pep8 fixes
pep8 fixes
more tests for websocket handshake
maxsplit should be 1 when a string is needed to split into 2 parts

str.split(sep, 2) will split a string into maximum 3 parts which is not desired
Merge pull request #158 from yhlam/parse_mimetype_maxsplit_fix

maxsplit should be 1 when a string is needed to split into 2 parts