Is there any way to force NSURLConnection to not reuse the current persistent connection but to create a new one ?
I am trying to defend myself from this known iOS8 keep-alive bug
If iOS 8 receives a HTTP response with a Keep-Alive header, it keeps this
connection to re-use later (as it should), but it keeps it for more
than the timeout parameter of the Keep-Alive header and then when a
second request comes it tries to re-use a connection that has been
dropped by the server.
I am looking for a way to solve this issue from Objective c rather than solving from server side.
If any third party libraries provides a way to ignore Keep-alive header then its also welcome.
This issue is somewhat related to following issues(1,2)
Any help is appreciated !
The only way I found is to use CFNetwork. Higher level API such as NSURLConnection or NSURLSession's Connection header will be overwritten by system.
Related
I am trying to find (or write) a caching proxy tool that accepts all traffic from a specific container in my localhost (using Iptables). What I want to do with this traffic is to save it and cache the response, and later, if I see that a request was already sent to a server, return the cached response to the requesting party (and not sending the request to the server again, because a previous similar request was already sent).
Here's a diagram to demonstrate what I'm trying to do:
I'm not sure exactly how big is the problem I'm trying to deal with here. I want to do it for all traffic, including HTTP, TLS and other TCP based traffic (database connections and such). I tried to check mitmproxy, and it seems to deal pretty good with HTTP and the TLS part, but intercepting raw TCP traffic (for databases etc.) is not possible.
Any advices or resources I can use to accomplish that? (Not necessarily in Python). How complex do you think this problem is? Do you think I can find a generic solution?
Thanks in advance!
Sorry for what I think might be a silly question but:
My understanding of HTTP 2 is that you create a connection, establish TLS if you want to, then upgrade to 2, and do lots of little queries on that one connection :. getting a speed increase because you're not re-establishing connections and TLS.
If this is true, When it comes to sessions - is each request over the connection treated as an unique request and :. has cookies and headers, or whether they're all treated as sub-requests of the original request?
This has impact on proxies whether you could merge requests from clients into a single stream or not?
My understanding of HTTP 2 is that you create a connection, establish TLS if you want to, then upgrade to 2
Not quite. If you use TLS then using HTTP/2 will be negotiated as part of the TLS negotiation. If you are not using TLS then you can upgrade but browsers only support HTTP/2 over HTTPS so that's the majority of the use cases.
When it comes to sessions - is each request over the connection treated as an unique request and :. has cookies and headers, or whether they're all treated as sub-requests of the original request?
Each request is part of what's call a stream in HTTP/2. It is a unique request, with it's own Cookies and Headers and is unrelated to the previous requests (though see note below for some caveats on this). Conceptually it's really no different than the fact that HTTP/1.1 allows you to send multiple unique, unrelated requests on the one connection - but unlike HTTP/1.1 multiple requests can all be in transit at the same time in HTTP/2 thanks to multiplexing.
This diagram might help explain it: https://freecontent.manning.com/mental-model-graphic-how-is-http-1-1-different-from-http-2/
This has impact on proxies whether you could merge requests from clients into a single stream or not?
I'm not sure what you mean by this?
Note: While HTTP/2 requests are independent of each other and HTTP is still stateless at a higher level, there are a few places when you go lower level where the strict wording of that could be challenged and where there is technically some connection between the requests. For example:
HTTP/2 actually uses HPACK header compression to compress HTTP headers so if the same header is sent twice on different requests (e.g. the same cookie) then the second call will include a reference to the previously received header, rather than repeat the data.
Each request has a unique stream id, which is an increasing integer which is either odd (client initiated) or even (server initiated) so of course the stream ids must be managed by the HTTP/2 implementation so arguable.
HTTP/2 push resources are pushed in response to a previous request stream id.
But these are all really just connection level issues and efficiencies. To a HTTP/2 user (e.g. a web developer) each HTTP/2 request is as independent as it was under HTTP/1.1 and HTTP is still stateless.
Is there a way to configure AFNetworking to reuse one single NSURLConnection for all requests going to the same host (until the connection is explicitly closed or results in an error)?
Or will I have to modify AFURLConnectionOperation myself?
I will be grateful for any hints on this subject. Thanks.
NSURLConnection manages its own connection pool. Use Keep-Alive and HTTP pipelining to increase the reuse of existing connections. Beyond that, there's nothing else to be done without dipping down into the underlying CFNetwork layer.
I have a ruby on rails app serving an API. It's legacy and we've already built a replacement on a more suitable stack, so no such suggestions in that direction needed :)
But we need to improve the performance on it regarding latency of response. I noticed keepalive was off. So I enabled it in apache. Now the static files from that server are responding with connection: keep-alive in the response headers. But the api (dynamic, rudy generated xml) still responds with connection: close. Sure enough it appears to be closing the connection on the client. Passenger is the Apache module used.
How can I make it use keepalive for the ruby generated responses?
Thanks
I can not reproduce this. I just tried, with Apache 2.2.3, passenger 3.0.12
The responses from my rails app do not have connection:close, they are kept alive. (They in fact have a Connection: Keep-Alive too, although I don't think HTTP 1.1 requires that.
So long as my apache has KeepAlive On.
I understand from various sources that the HTTPS handshake is the heaviest part of using HTTPS. I'm using POSTs internally between my servers to communicate information and would like to use HTTPS for it. I wondered how long the actual HTTPS handshake lasts/"stays open"? Is it re-done for each POST I'm sending to a server, or what is the lifetime?
The SSL handshake is only done at the beginning of a session and is mainly about generating a shared session key that is used to encrypt all later traffic.
You can find a very good description of the handshake here.
I believe the handshake occurs on connection (ie, as part of the SSL negotiation). It you use HTTP keep-alive connections then the handshake only occurs once as long as the connection is active.
I don't know the particulars, but I'm sure the handshake is supposed to occur only when the session is started. It would be too expensive otherwise.
Edit: Here's a nice description of the process.