GNOME Bugzilla – Bug 585565
Spool to local cups server
Last modified: 2009-07-14 11:03:40 UTC
Please describe the problem: A CUPS developer wrote in http://www.cups.org/str.php?L3164: The GNOME folks should NOT be reconnecting to spool directly to the server reported in the printer-uri-supported attribute - all jobs can and should go through the local server. I mentioned this already in bug 429845 comment 19, but as that bug was now closed without this issue being addressed, I open this new report here to deal with it. I expect the CUPS people know how their system is intended to be used. Steps to reproduce: Print a document to a remote CUPS printer. Actual results: The application seems to talk directly to the spooler of said printer. Expected results: The document should be sent to the local cups server, which will deal with it in an appropriate manner. Does this happen every time? Yes. Other information: If in doubt, contact CUPS people to discuss stuff with them. Please post pointers to any such discussion here.
Hi Martin, could you be more specific in this part: "The application seems..." ? Don't you see the job in local queue (http://localhost:631/jobs?which_jobs=all)? Thank you Marek
(In reply to comment #1) > could you be more specific in this part: "The application seems..." ? > Don't you see the job in local queue I only have a single cups server in my net, so I didn't see this issue locally. Instead, my understanding of this bug comes from looking at the source and examining its behaviour in a debugger. I'll try to reproduce my investigations here, looking at this source: http://git.gnome.org/cgit/gtk+/tree/modules/printbackends/cups/gtkprintbackendcups.c?id=927e7209a5b6115b22ba8880495b53c147424112 I'll restrict my quotation to the lines involved, and drop some parameters as well. static void cups_request_printer_list_cb (...) { if (strcmp (attr->name, "printer-uri-supported") == 0 && ...) printer_uri = attr->values[0].string.text; cups_printer->printer_uri = g_strdup (printer_uri); httpSeparateURI (cups_printer->printer_uri, hostname, &port, ...); cups_printer->hostname = g_strdup (hostname); cups_printer->port = port; } static void cups_request_ppd (GtkPrinter *printer) { http = httpConnectEncrypt (cups_printer->hostname, cups_printer->port, ...); } So what we have is that the system asks cups for a list of printers. For each printer, a hostname and port is extracted from the printer-uri-supported attribute, and that hostname and port is used upon a subsequent connect to the queue of this specific printer. I noticed this when debugging bug #429845: httpSeparateURI would in some cases return ::1 as the IPv6 localhost address, which would cause trouble for httpConnectEncrypt later on, as it resulted in an invalid value for the "Host" HTTP request header. So the control flow outlined above has been actually observed, even though the host connected to was localhost in all cases. When I reported this issue with the CUPS bug tracker, at http://www.cups.org/str.php?L3164 , they recognized it as a bug in cups and fixed the internals of httpConnectEncrypt to deal with IPv6 addresses correctly. However, they also pointed out that the strategy followed by gtk+ does not agree with the intention of CUPS, as I quoted above. I'm no authority on CUPS or IPP, so I'm ill equipped to argue that point, but if a CUPS developer says so, I'd trust him on this. It also sounds reasonable to me that a CUPS server providing a list of printers would also be willing to spool documents for any of these printers, and probably do so in a more flexible way than each app talking to each spooler directly. So while I don't know the technical reasons behind it, and neither know how to tell a CUPS server to spool a document for a certain printer, the idea makes a lot of sense to me.
The reason for: static void cups_request_ppd (GtkPrinter *printer) { http = httpConnectEncrypt (cups_printer->hostname, cups_printer->port, ...); } is that we want to download PPD files in non-waiting manner. This is also the reason why Gtk+ doesn't use cupsGetPPD*() functions. Jobs are spooled correctly to the local server (or to the server stated in client.conf). This is achieved by NULL passed as fifth parameter of gtk_cups_request_new* which induces connecting to the server given by cupsServer() (except the getting of PPD files). Marek
OK, I missed the fact that this line was only about PPD files. I still don't understand that "non-waiting manner" stuff, but I don't think I have to. I'm a bit worried about setups where direct communication between client and printer is impossible, e.g. blocked by some firewall or change of communication media, so the spooler HAS to be used. Don't know if there are any real world setups like this, and if they would cause a problem the way I imagine them to. If you are certain that this way to get PPD files is both legal and desirable, feel free to close this as NOTABUG.
Hi, the non-waiting means that we don't block whole application because of download of the ppd file. It is implemented in similar way as cupsGetPPD3 () is. I consulted it with a CUPS developer. I'm closing this bug. Regards Marek