[cups.bugs] [HIGH] STR #2892: Firefox 3 and https connections

[twaugh.redhat]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

I know you've seen bug reports about this before and closed them, but I
think I've uncovered the cause of it, and it is CUPS after all.

In Firefox 3, SSL traffic is sent in fewer packets than in previous
versions, so clicking on 'Continue' in the CUPS web interface when adding
a printer may only send one single large packet.

What I have observed is that when data is available to read on a
connection, and this is SSL data, it will read in a buffer full and
process it.  However, when cupsdReadClient finishes, the scheduler will
not wake up until the next time poll() says there is data to read.

The problem is that it has already *been* read, by the SSL library
(gnutls, in the case I'm examining).  The data is sitting waiting to be
discovered by gnutls_record_check_pending(), but this function is never
called after cupsdReadClient returns, at least not until the user clicks
'Stop' and the connection is closed.

At that point, the scheduler wakes up and processes the data -- but by
then it's too late.

Attached is a function that wraps cupsdReadClient() and just calls it
again if more data is available.  This works around the problem for me.

Full steps for reproduction:

Build CUPS against gnutls (not sure if this is relevant)
Using firefox 3, go to https://localhost:631
Click 'Add Printer'
Enter the name as 'test' and click Continue
Select AppSocket/HP JetDirect for the device and click Continue
Enter socket://hostname as the URI and click Continue
Select any make from the list and click Continue

At this point, the browser is waiting for data, and so is CUPS.  With the
patch applied, CUPS responds with a model list page.

Link: http://www.cups.org/str.php?L2892
Version: 1.3.7
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cups-firefox3.patch
URL: <http://lists.cups.org/pipermail/cups-devel/attachments/20080801/5cc8a032/attachment.ksh>