When multiple headers have the same value in SPDY/3, they are concantenated
and separated by \u0000.
When multiple headers have the same value in HTTP/2, they are each written
independently.
This fixes the problem and rearranges the code to share less behavior than
previously. It gets us closer to being able to drop SPDY/3.
Closes https://github.com/square/okhttp/issues/1906
There's a race where the HTTP engine has been created, but not yet connected
and the cancel isn't as immediate as it could be. Fix the test by making sure
there's a response to be retrieved.
With the upcoming connection pool changes we might make the implementation
more robust.
Closes: https://github.com/square/okhttp/issues/2001
This was updating the protocol as a side-effect of an HTTP/1.0 response.
This made the protocol field mutable, and the code more difficult to
trace.
One consequence of this change is that OkHttp will attempt HTTP/1.1 for
all requests, even if a server returns HTTP/1.0 from the first response.
This is closer to our implementation anyway.
> If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension MAY discard the request body.
This breaks apart the states used to track sending a close message and whether or not the connection has been closed. Prior to this, certain threading orders would allow multiple calls to close() which would attempt to remove ownership of the connection, the second of which would fail.
This is intended to replace some of the state machines in HttpConnection, HttpEngine,
and ConnectionPool. With this we'll keep track of all streams in flight, not just
the connections currently idle.
Note that I've sketched this out into a new Connection.java class. In a follow up
change I'll attempt to combine this with the existing Connection class.
The test relies on small client send / server receive buffers
to force blocking and generate a timeout.
The switch to make MockWebServer a @Rule (commit
785d9e9438) moved the
MockWebServer.start() call earlier in the test execution.
Setting the ServerSocketFactory became a no-op so the server
receive buffer size was left as the default.
The test became reliant on either:
1) The default server socket receive buffer being small enough
(e.g. less than the data being transmitted).
2) The device being too slow to send the requested data in the
time allowed.
The test was recently made less reliable by:
1) The okio commit
f30955cb15eb234f874dd55819686832c960765b, which made the segment
size bigger (increasing throughput / transfer efficiency).
2) The OkHttp commit f30955cb15eb234f874dd55819686832c960765b,
which reduced the amount of data being sent in the test from
16MB to 2MB.
3) Recent Android devices have large default buffer sizes. e.g.
Nexus 5: 1MB, Nexus 5X: 6MB.
Previously we were treating null as a sentinel 'canceled' value
for application interceptors, and crashing on network interceptors.
Closes https://github.com/square/okhttp/issues/1921
