-
Notifications
You must be signed in to change notification settings - Fork 469
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Firefox 3 and https connections #2892
Comments
CUPS.org User: mike OK, right idea, but wrong implementation. We really only need to update the data reading code in cupsdReadClient to use the equivalent of httpCheck instead of only looking at con->http.used. Patch coming up... |
CUPS.org User: mike Here you go... I've tested this with FF3 on Mac OS X (CDSA) and RHEL5 (OpenSSL), but not a system that uses GNU TLS. However, I did copy the code from http_wait() (which is what httpCheck() uses), so I'm pretty confident that GNU TLS installs will be fixed as well. Let me know how your testing goes... |
CUPS.org User: mike and here is a patch against 1.3.x since the 1.4.x patch didn't apply cleanly... |
CUPS.org User: twaugh.redhat The 1.3.x version works fine here with gnutls. I haven't tested the trunk version. Thanks! |
CUPS.org User: mike Fixed in Subversion repository. |
"cups-firefox3.patch": diff -up cups-1.3.7/scheduler/client.c.firefox3 cups-1.3.7/scheduler/client.c
-void +void
/*
|
"str2892.patch": Index: scheduler/client.c--- scheduler/client.c (revision 7817)
+/*
+#ifdef HAVE_SSL
|
"str2892-1.3.patch": Index: scheduler/client.c--- scheduler/client.c (revision 7820)
+/*
+#ifdef HAVE_SSL
|
I've got an old ubuntu Server with this Bug present. How do I patch my CUPS version with these files? |
@vgavgavga Contact the Ubuntu folks - there isn't anything we can tell you here, unfortunately... |
Version: 1.3.7
CUPS.org User: twaugh.redhat
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.
The text was updated successfully, but these errors were encountered: