1

I have an IPad Safari sending two HTTP requests (two different PNG) files within 30 ms.

I thought that even on a Keep Alive HTTP 1.1 connection there should be a clear sequence of request/response.

What I saw is that the Safari browser sends two GET requests within 30 ms without waiting for an answer. This causes problems in some web servers.

Situation: I have an HTML5 loading an SVG with further references to other images (like PNG and GIF). The problem does not occur on IPhone 5 but on the IPad.

Please seee this wireshark dump: http://tinyurl.com/c7m37b9 (Frame 116/117)

IPad (1) Infos: Version 5.1.1 (9B206) Model MB2292FD Safari 5.1

[GET /Licht_3.gif HTTP/1.1
...
User-Agent: Mozilla/5.0 (iPad; CPU OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML,      like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3
Accept: */*
...
Accept-Language: de-de
Accept-Encoding: gzip, deflate
Connection: keep-alive]

[GET /Licht_3.gif HTTP/1.1
Host: 192.9.225.251:8081
...
Accept-Language: de-de
Accept-Encoding: gzip, deflate
Connection: keep-alive]

[HTTP/1.1 200 OK
...
Content-Type: image/png
Content-Length: 3921]
Matthias
  • 1,386
  • 3
  • 24
  • 59
  • Are you sure that's what's happening, and they're not just being misordered in wireshark? It looks like those requests are being responded to correctly in the Wireshark Trace. – Kylar Mar 26 '13 at 01:51
  • The second request is to port 8081. Which port is the first request to? The default 80? There is normally not a problem with sending multiple requests at once when each request is for a different resource. Requests on different ports will appear as requests for different resources. – Octopus Mar 26 '13 at 07:34
  • Yes, that exactly the problem, both HTTP GET requests are sent on the same time (~30 ms) and on the same keep-alive socket (same source and destination port). And the web server does only answer, 600 ms later, on the first request, causing the client to be stuck! Actually, I never seen that before and I'm wondering if the problem comes from client or from the server? is that HTTP1.1 compliant? – Matthias Mar 26 '13 at 11:40

3 Answers3

2

It looks like HTTP pipelining:

HTTP pipelining is a technique in which multiple HTTP requests are sent on a single TCP connection without waiting for the corresponding responses.

rhashimoto
  • 15,650
  • 2
  • 52
  • 80
1

I think that this may be due to browser adhering to HTTP 1.1 Spec 8.2.4. which does allow client to retry the request if client is connected to server thru a middle layer and doesn't get a response from server before the connection is closed.

I have seen this error and have found following links to be helpful.

https://www.ravellosystems.com/blog/beware-http-requests-automatic-retries/

http://geek.starbean.net/?p=393

curiousone
  • 11
  • 2
0

I am seeing this too from a mobile safari client. The only workaround I was able to find is to disable keepalive for the whole server in Nginx. We don't get duplicate requests and/or pipelining might not work from the Safari client when keepalive is disabled.

In Nginx, there is a keepalive_disable option, but it only works for POST requests on certain browsers, and doesn't have many options. We ended up disabling keepalive on that server using keepalive_timeout 0; I hope there is a better solution in the future.

I would think that a correct use of pipelining would submit multiple differing requests, instead of duplicate requests.

TheJeff
  • 3,665
  • 34
  • 52