| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
TCM service indicates to close the TCP idle connections
on time so that the application servers do not time out
on connection and wake the modem cellular data connection
up and cost power.
Change-Id: I0c041eb46f9d4be1b9fbce677b8da5cb458a85b0
|
|\
| |
| |
| |
| | |
* commit 'aa83190cb650e9b714f2b980aa29ece8f86d587a':
Honor NetworkSecurityPolicy regarding cleartext traffic.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This makes HttpClient instances honor the process-wide policy about
cleartext network traffic. If cleartext network traffic is not
permitted, then attempts to send a cleartext HTTP request will throw
an IOException.
This change is needed despite platform-provided HttpClient being
deprecated because a large fraction of applications still use this
HttpClient library to generate HTTP traffic instead of using
URLConnection.
HttpClient is modular -- most of its parts can be replaced with
alternative implementations. Thus, this CL enforces the cleartext
traffic policy in DefaultRequestDirector because RequestDirector is
least commonly replaced (if ever) and there are no other
RequestDirector implementations provided by the library.
The cleartext policy is enforced pretty late in the process of
emitting a request to give time for any HttpRequestInterceptor
instances to see the request. This is because some apps use a
HttpRequestInterceptor to enforce their own policies about cleartext
HTTP such as catching accidental use of cleartext HTTP and reporting
it to their servers for analysis.
Bug: 19215516
Change-Id: I03687123080475581e7196d9bb8c0d006502d056
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Lets us build it from source on both unbundled and platform
branches. The main changes are :
- We need a placeholder "WebAddress" class that's used internally.
The class will be deleted from the frameworks once the webview
stops using it (sigh...)
- Use TrafficStats instead of SocketTagger.
- Remove @hide annotations because they don't matter any more. We're
not building stubs any more, and apps in both unbundled and platform
branches will compile directly against the jar. We don't care about
any of that because this is all deprecated API and deleted from the
API specification.
bug: 18027885.
Change-Id: I6b5f06db2e3e0e34ccd7264c15e1fe594e61862e
|
|/
|
|
|
|
|
|
|
|
|
|
| |
.. and move some parts of apache-http into the framework. The parts that
have been moved need to be in the bootclasspath because we have public API
that returns org.apache.http.conn.ssl.SSLSocketFactory :( .
This change also removes the placeholder library shim.
bug: 18027885
Change-Id: I37aa7562bcd5e05191b83676fae4533e03b86d1d
|
|\
| |
| |
| |
| |
| |
| | |
generation"
* commit 'c7fe4b3752acbf8a183fa6d4e07bc2acbb3448fd':
Fix @link annotation in documentation for hyperlink generation
|
| |
| |
| |
| |
| | |
Change-Id: Ia01f2d4d523b2fbb3ed227f003218841e00e608c
Signed-off-by: Ruey-Shi Rau <timrau@gmail.com>
|
|/
|
|
|
| |
bug: 18067888
Change-Id: I8d830c20e952734e2bb63da1e785094b7a783308
|
|
|
|
|
|
|
|
| |
This switches AbstractVerifier to the DN parser used by the platform
default HostnameVerifier.
Bug: 16510257
Change-Id: Iedd27cec162167dad11a4fe477d4eaa3eba004b7
|
|
|
|
|
|
|
|
|
| |
During Zygote initialization, the class may be preloaded. However we do
not want the default instances of SSLSocketFactory initialized, so move
those into a holder class so they are only initialized when used.
Bug: 9984058
Change-Id: Icf91f4fb60b7e4e5e9fbb22def01073dc1663128
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|