On 31 jul 2013, at 18:01, Samuel Vogel wrote:
>> 2013/7/31 Sake Blok <sake@xxxxxxxxxx>
>> On 31 jul 2013, at 17:03, Samuel Vogel wrote:
>> > 2013/7/31 Sake Blok <sake@xxxxxxxxxx>
>> > On 30 jul 2013, at 19:21, Samuel Vogel wrote:
>> >
>> > > I'm debugging a situation where we see duplicate HTTPS requests from iOS 5 & 6 devices with nginx 1.4.1. The first request seems to be cancelled by the client, but the package gets lost and now the new, repeated and the original request are both executed. This way the article ends up in the shopping cart twice.
>> > >
>> > > Only one request is actually seen by iOS Safari / jQuery. This issue is reproducible most of the time (lets say 75 % of the cases) on two completely different servers with different hosting providers (Hetzner & Host Europe in Germany) but not with different browsers. It always follows the exact same pattern.
>> > > I'm pretty sure this can't be coincidental anymore, but have now idea what could cause this. It would be great if anybody could have a look at my capture:
>> >
>> > Are you able to share your capture (here or on www.cloudshark.org) and an export of the SSL session keys (File -> Export -SSL session keys)? There is not enough information in the text output to really help you analyze this issue.
>> > sure, I've uploaded it here: http://www.cloudshark.org/captures/3e090ddc98f7
>>
>> Uhmm.. it does not contain the full sessions. Could you upload the whole file? Of at least the full tcp session of the two requests (look at the stream number in the TCP details and use a filter "tcp.stream==x or tcp.stream==y and then use "File -> Export Specified Packets...")
> sorry, here are both TCP streams:
> http://www.cloudshark.org/captures/fceaea90e3b3
OK, I checked the streams. Looking at the RTT of the connection in the 3-way handshake I get about 48ms. I also see that the trace was made at the server-side. The GET request and the SSL Close Notifiy come into your server only about 100 us apart, so the client (iPad) actively shuts down the connection before waiting on a response. Also the resending of the request is done only 699 us after the first request, so it could not be a user-action. I suspect there is something on the site that does not play nice with the iOS Safari browser and makes it abort the request. Do you see the same behavior with other objects on the site?
Cheers,
Sake
