[cl-plus-ssl-devel] concurrency problems when used with chrome?

[Attila Lendvai]

[my original mail needs moderation due to size limits, so resending
now without the wireshark file.]

a short update on the issue:

Luís suggested (off-list, probably accidentally) that it might be due
to an SSL optimization called "False Start". originally it's been
implemented by Chrome, then picked up by ff4 (disabled by default),
but this seems to be unrelated to my problems.

in spite of that, here's some detail for the interested parties:
about:config
security.ssl.enable_false_start

https://bugzilla.mozilla.org/show_bug.cgi?id=525092
http://www.carbonwind.net/blog/post/Random-SSLTLS-101-False-Start.aspx


then i've looked at what's happening with wireshark, and it's rather
strange. chrome (12.0.742.53 beta) seems to be bombing my https port
with half a dozen of connections, while with firefox i only see a
single connection in wireshark (this is the first time i've used
wireshark, so i've attached the chrome capture for more trained eyes.
it's reloading a single static image.).

but normally a web server needs to deal with the remote end
prematurely hanging up the connection in a graceful manner anyways
(e.g. not to flood its log files with uninteresting backtraces), so
i've extended the already implemented support for the ssl stream
errors. for that i needed some changes to cl-plus-ssl which is
attached, but more on that below.

now my server properly ignores normal premature hangups, which BTW can
also be reproduced by tapping F5 in firefox or other browsers. it
deals with the problem, but chrome's behavior is still weird... later
on i'll try other versions to see if this is a temporary chrome bug,
because searching the net haven't yielded anything useful regarding
this.

a pure speculation about a possible optimization: maybe chrome
preemptively opens several connections to build up the SSL handshaking
in them, so that later on requests can be finished with lower delays?
then at the end closes these connections when it sees that the
downloaded content doesn't need any new requests?

as of the attached patch: i'd need something along these lines (e.g.
stream-error subclasses being signaled when errors come from stream
operations), but it has some controversial changes. for example gluing
ssl-signal-error for usage with streams only as opposed to using it in
lower-level ssl code.

the patch also has some random unrelated notes and a fix, too.

any thoughts?

--
 attila

Notice your eroding (digital) freedom, and do something about it!

PGP: 2FA1 A9DC 9C1E BA25 A59C  963F 5D5F 45C7 DFCD 0A39
OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06
BitCoin: 154uf86Vd9rpjMULd9CXa7nVwikknYZJiB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cl-plus-ssl.diff
Type: text/x-patch
Size: 5510 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-plus-ssl-devel/attachments/20110524/a1512f89/attachment.bin>