Fails on informational (1xx) responses from upstream

[vfaronov]

Steps to reproduce the problem:

1. Start netcat listening on local port 8765: nc -lC 8765
2. Start mitmproxy as a reverse proxy: mitmproxy --mode reverse:http://localhost:8765
3. Make a request to mitmproxy: curl -v localhost:8080/
4. Type the following into netcat:

HTTP/1.1 103 Early Hints
Link: </logo.png>; rel=preload

HTTP/1.1 200 OK
Date: Wed, 05 Apr 2017 07:06:41 GMT
Content-Type: text/plain
Link: </logo.png>; rel=preload
Content-Length: 12

Hello world!

mitmproxy sees the 103 response and thinks it is the final response from the server.

Any other comments? What have you tried so far?

The most familiar 1xx response is probably 100 (Continue), but there are others, like the upcoming 103 (Early Hints) I used for this example.

RFC 7231 § 6.2:

A client MUST be able to parse one or more 1xx responses received
prior to a final response, even if the client does not expect one.

Ideally mitmproxy would forward these responses, which probably ties into #1721. An easier intermediate solution might be simply to discard them.

System information

(from Git master)

Mitmproxy version: 3.0.0 (release version)
Python version: 3.5.2
Platform: Linux-4.4.0-72-generic-x86_64-with-Ubuntu-16.04-xenial
SSL version: OpenSSL 1.0.2g 1 Mar 2016
Linux distro: Ubuntu 16.04 xenial

[mhils]

Yes, thanks for catching this!

refs #1775.

[v-p-b]

I also hit this bug.

Can you point me to any workarounds that allow me to see the rest of the received content after the initial HTTP 1xx header?

EDIT: I found that setting flow.request.http_version="HTTP/1.0" for requests works around the problem for me.

[mhils]

duplicate of #5050 (which has a nicer traceback)