Previously we could close an SSL socket which does synchronous I/O. This
made it unreasonable to cancel a call on a UI thread.
Closes: https://github.com/square/okhttp/issues/1592
* rnauber-rnauber_remoteDNSwithSOCKS:
Use bogus pin that doesn’t throw an exception
Log the full URL.
Log level getter.
Remove synthetic protocol header from native API.
Force logging of headers from the request body.
Support 204 and 205 'No Content' replies when application interceptor.
Remote DNS resolving for connections through a SOCKS proxy
Also formalize HttpURLConnection-only 'Response-Source' synthetic header to be on par with the protocol header (which is retained for this legacy interface).
Also formalize HttpURLConnection-only 'Response-Source' synthetic header to be on par with the protocol header (which is retained for this legacy interface).
This small patch ensures that a connection through a SOCKS proxy will have its hostname resolved through the proxy as well. It includes a test case for that behaviour.
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.
