| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
This switches AbstractVerifier to the DN parser used by the platform
default HostnameVerifier.
Bug: 16510257
(cherry picked from commit ec8c48dd748c81ba2cce518bf83cb9f236c30bae)
Change-Id: I8124b54801481065df5230c1277e59c5e602b2b9
|
|
|
|
| |
Change-Id: I596a7c461eacd56457b3d10120f51afc7bafa905
|
|
|
|
| |
Change-Id: I97a1a139fbe95cf63b1f921daea9e4c55c118a7f
|
|
|
|
|
| |
Bug: http://code.google.com/p/android/issues/detail?id=17073
Change-Id: I957549860d0b61acc08924156d5c43b7d182c27d
|
|
|
|
|
|
|
|
|
| |
When the HTTP client encountered a server failure while
talking through a proxy, it fails with an NullPointerException
and not an IOException.
Bug: http://b/5372438
Change-Id: I67848d52f5d01c9e353fcc7d66d48ec821d9b4ba
|
|
|
|
|
|
|
|
|
| |
Previously we'd fail IPv4 if IPv6 failed with a EHOSTUNREACH
error (which may be thrown as a SocketException or as a
NoRouteToHostException, depending on the platform).
Bug: http://b/5293809
Change-Id: Idca2e9bd561a23cff88b1399d45db65b96980148
|
|
|
|
| |
Change-Id: I989f7ecab7e4fd1cf21bbe0782e960dfe3b4c8e8
|
|
|
|
|
| |
Change-Id: If80c5f6ecca609abdb3b274e00b8ea8a75248f23
http://code.google.com/p/android/issues/detail?id=16051
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Changes SingleClientConnManager and ThreadSafeClientConnManager to tag
any recycled Sockets based on the current thread. (Actual tagging is
maintained and applied in BlockGuard.)
Change-Id: Ib34897bb2af8641fa65adc664f7858f9d43ffeeb
|
|\ \
| |/
|/|
| |
| | |
* commit 'e30b5b55806b31d1a61e2885b854dd7b8da1a07a':
Make Apache HttpClient play nice with large kernel socket buffers.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Given the large maximum size likely to be set for kernel socket buffers on LTE
devices, we need to stop Apache HttpClient from allocating some integer
multiple of that size on the heap for each socket. On one device, 16 HTTP
connections would fill the heap.
Bug: 3514259
Change-Id: I888c03b6ad4b7ca444c2c423b097a3f76390846b
|
|/
|
|
|
|
|
|
|
|
| |
From libcore's commit with sha 6767bdbe6bb1d4542c97868d8df1f71d2414fc62
The only behavior change should be a bug fix. There was a check
"cn.lastIndexOf('.') >= 0" that was always true. This has been
fixed to match the comment "require two dots".
Change-Id: I680cad56a1f86150128e587f8c8e19be6ef27bc3
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had problems where we gave a cryptic error when the user's request
URL like "www.example.org/api/json/get_stuff" is interpretted as a relative
path rather than a fully qualified address:
java.lang.IllegalStateException: Target host must not be null, or set in parameters.
The new message breaks the address into parts to make this more clear:
java.lang.IllegalStateException: Target host must not be null, or set in parameters. scheme=null, host=null, path=www.example.org/api/json/get_stuff
Change-Id: Ie102718dc15b92d68835f1c34b538639f500eeaa
http://code.google.com/p/android/issues/detail?id=9929
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DefaultRequestDirector was letting IOExceptions from closing stale
connections affect new requests. However, it was very common to
received "SSL shutdown failed" exceptions in this case, since an SSL
"close notify" message could not be sent. Now these and other
IOExceptions are ignored so the request can continue with a new
socket.
Bug: 3317717
Change-Id: I72f6f4a8f70aacb8b4c3e93c51e9808742d1a605
|
|
|
|
|
|
|
|
|
| |
android.net.http.DefaultHttpClientTest demonstrates a problem where
half-closed connections get pooled, causing subsequent connections
to timeout.
Change-Id: I7275d99f12eafa28bb2336a3dd67546ffecb4dce
http://b/2612240
|
|\ |
|
| |
| |
| |
| |
| | |
Change-Id: Ic05f450a301d5478ff3a8f03af56ac0c0dbe3620
http://b/3254717
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even though SoTimeout, TcpNoDelay, and SoLinger can be specified per
request in HttpParams, these values are only set on the underlying
socket in the DefaultRequestDirector when ManagedClientConnection.open
is called to create a new connection. On reused connection, no setting
of Socket options was being done.
There does not seem to be an easy way to fix this without changing one
or more APIs but for the timeout case at least, we can use the fact
that the ManagedClientConnection is an HttpConnection which has a
setSocketTimeout method.
Bug: 3241899
Change-Id: I080147b017b961502b3ba98d40841fea679491eb
|
|
|
|
|
| |
Change-Id: Id3a171f588fb545e14188e69e7bf6f2d4ef25b5c
http://b/3095990
|
|
|
|
|
|
|
|
| |
This needs a comment and an annotation. The original deprecation was
submitted in HTTPCORE-148, in this patch:
https://issues.apache.org/jira/secure/attachment/12376138/changes.txt
Change-Id: I3b4c6e61f03a5f6ffc42ac1f02155f5c58b2e79c
|
|
|
|
|
|
|
|
|
| |
git cherry-pick --no-commit 5648c97be2c515bdafeff3d8a4b07ea0ddc3e357
git cherry-pick --no-commit ffdb1757
git cherry-pick --no-commit 9340bb2a4b5f828b418c0e77492dde148623c938
git cherry-pick --no-commit af5c56d1
Change-Id: Ie910601ca27e1fcff90bbf0db5bd522bab8924f7
|
|
|
|
| |
Change-Id: Idadf71f9935d34f95e7df68a3ffb59e0d8f154b8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DefaultClientConnectionOperator.openConnection was recently changed to
use LayeredSocketFactory.createSocket(Socket, ...) to create an
SSLSocket around a plain java.net.Socket. However, this means code in
LayeredSocketFactory.createSocket(Socket, ...) is called before socket
options such as timeout are set by
DefaultClientConnectionOperator.prepareSocket. However, the default
org.apache.http.conn.ssl.SSLSocketFactory.createSocket(Socket, ...)
performes the SSL handshake to perform hostname verification, meaning
the handshake is performed without timeouts set.
This change to DefaultClientConnectionOperator.openConnection moves
the call prepareSocket to be on the underlying java.net.Socket before
it is has the SSLSocket layered on top of it to prevent hangs during
SSL handshakes.
Change-Id: If705cc1acfe524281ec1338f73eccf7c0f4d1227
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch makes our HTTP client multihoming-aware, so if one server fails for
whatever reason (including timeout), we'll fall back to the next. It's a bit
more complex than the first attempt, but we're hopefully not breaking SSL
connection (incl. checkin) anymore.
Also includes one patch from upstream, in that timeouts are converted from
Java's exception hierarchy to our own exceptions.
Here's an example tcpdump from a fake checkin server with both AAAA and A records,
where the IPv6 connectivity is deliberately broken to demonstrate the effects of
this patch:
11:49:28.202620 IP6 2620:0:105f:a:223:76ff:fe8d:3a3c.37109 > 2001:700:300:1880::2.80: S 24035192:24035192(0) win 5760 <mss 1440,sackOK,timestamp 1110775 0,[|tcp]>
11:49:31.211370 IP6 2620:0:105f:a:223:76ff:fe8d:3a3c.37109 > 2001:700:300:1880::2.80: S 24035192:24035192(0) win 5760 <mss 1440,sackOK,timestamp 1111075 0,[|tcp]>
11:49:37.211186 IP6 2620:0:105f:a:223:76ff:fe8d:3a3c.37109 > 2001:700:300:1880::2.80: S 24035192:24035192(0) win 5760 <mss 1440,sackOK,timestamp 1111675 0,[|tcp]>
11:49:48.216299 IP 74.125.57.33.58205 > 129.241.93.35.80: S 2632654863:2632654863(0) win 5840 <mss 1372,sackOK,timestamp 1112775 0,nop,wscale 1>
11:49:48.216324 IP 129.241.93.35.80 > 74.125.57.33.58205: S 3149921981:3149921981(0) ack 2632654864 win 5792 <mss 1460,sackOK,timestamp 62633484 1112775,nop,wscale 8>
(...)
and then the HTTP connection proceeds as usual.
I intend to push this fix upstream once we get it reviewed and committed locally.
|
|/
|
|
|
|
|
|
| |
past the start of the read buffer.
Fixes internal bug #2183785.
Change-Id: I2a371e88a6816f4c1e237ae4cdb8baade4de66c9
|
|
|
|
|
|
| |
whatever reason"
This reverts commit ceab342827538782a715a10e5030a222700895ce.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(including timeout), we'll fall back to the next.
Also includes one patch from upstream, in that timeouts are converted from
Java's exception hierarchy to our own exceptions.
Here's an example tcpdump from a fake checkin server with both AAAA and A records,
where the IPv6 connectivity is deliberately broken to demonstrate the effects of
this patch:
11:49:28.202620 IP6 2620:0:105f:a:223:76ff:fe8d:3a3c.37109 > 2001:700:300:1880::2.80: S 24035192:24035192(0) win 5760 <mss 1440,sackOK,timestamp 1110775 0,[|tcp]>
11:49:31.211370 IP6 2620:0:105f:a:223:76ff:fe8d:3a3c.37109 > 2001:700:300:1880::2.80: S 24035192:24035192(0) win 5760 <mss 1440,sackOK,timestamp 1111075 0,[|tcp]>
11:49:37.211186 IP6 2620:0:105f:a:223:76ff:fe8d:3a3c.37109 > 2001:700:300:1880::2.80: S 24035192:24035192(0) win 5760 <mss 1440,sackOK,timestamp 1111675 0,[|tcp]>
11:49:48.216299 IP 74.125.57.33.58205 > 129.241.93.35.80: S 2632654863:2632654863(0) win 5840 <mss 1372,sackOK,timestamp 1112775 0,nop,wscale 1>
11:49:48.216324 IP 129.241.93.35.80 > 74.125.57.33.58205: S 3149921981:3149921981(0) ack 2632654864 win 5792 <mss 1460,sackOK,timestamp 62633484 1112775,nop,wscale 8>
(...)
and then the HTTP connection proceeds as usual.
I intend to push this fix upstream once we get it reviewed and committed locally.
|
| |
|
| |
|
| |
|
| |
|
|
|