On Thu, 2013 Jun 20 11:39-0400, Michael Sweet wrote: > > In both cases the server is returning a "bad request" error instead of > "version not supported". We could (and probably should) change lpq to > report the real error, but that will just yield: > > lpq: Bad Request > > And since "Bad Request" can be caused by a grab bag of issues, we > can't just map it to "version not supported".
Now that it is possible to configure a new client to talk with an old server, and that the means of doing so is documented (in Debian currently, and upstream soon), we need this problem to be diagnose-able. When I first saw the errors Vincent quoted above, I had no idea what to do. Printing worked on older Ubuntu system images, but not on a new one, and there were a hundred-and-one things that had changed between releases that could have been at fault. Ultimately, the only way I could determine what was going on was to sit down with Wireshark, try to print, and inspect the network chatter of the failed request. Only then was I able to find the relevant bug reports. It is not reasonable for a user to have to sniff CUPS network traffic in order to diagnose an IPP version incompatibility. I think that lpq and lpstat (any others?), being the most obvious tools for verifying basic connectivity with the CUPS server, need to go the extra mile to detect this kind of situation so that the user can be alerted to it. Maybe if the tool gets a "Bad Request" error, it can do a version probe... whatever makes the most sense. I'm not going to argue for automatic protocol downgrading when that's already been considered, but I will argue that returning a nonspecific "Bad Request" error (or spurious "Unknown destination" error) for this particular failure mode places an unacceptable burden on users wondering why their latest and greatest Linux system is unable to print at all. (I would agree that a "cupsversion" utility isn't such a hot idea, albeit because the user would have to be aware of the IPP version being an issue in order to know to use such a utility in the first place.) -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1371785883.20640.140661246479909.4ceac...@webmail.messagingengine.com
