Re: Duplicate HTTPS requests from iOS

[Sake Blok <sake () euronet nl>]

On 31 jul 2013, at 18:01, Samuel Vogel wrote:
> > 2013/7/31 Sake Blok <sake () euronet nl>
> > On 31 jul 2013, at 17:03, Samuel Vogel wrote:
> > > 2013/7/31 Sake Blok <sake () euronet nl>
> > > 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
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe