CUPS and unhelpful error messages

I’m currently trying to set up my HP PSC 1410 printer with CUPS. For a bit I was getting this message, when I tried to print a web page via the CUPS web interface:

Error: Unsupported format ‘application/postscript’!

Well, it turns out the problem was I needed to update my ghostscript version to one that included the “pstoraster” filter (specifically, GNU ghostscript 8.60, though I assume GPL ghostscript 8.60/8.61 would be fine also. Let’s not get started on the ridiculous number of ghostscript variants; I’ll save that for another day). I could have been saved quite some time if this had been made more clear by the error message. How about something like:

Unsupported format ‘application/postscript’: Could not find “pstoraster” filter specified in /etc/cups/mime.convs file

That would be much more helpful! Yes, I understand it might not be meaningful for a casual PC user but then the original message is not helpful in that case anyway. Oh, and it gets rid of that annoying exclamation mark.

Still haven’t got the printer working though; now it just starts a whole bunch of processes (foomatic-rip, gs) which all just seem to hang.

Update: Ok ,several hours later I have got it working. It was permissions; I had to modify udev rules so that the usb device nodes were created with the right group and permissions. Incidentally, hplip (HP’s software) includes a udev rules file but it’s outdated (uses SYSFS instead of ATTR) and insecure (sets mode 0666 instead of 0660). I don’t know why the driver doesn’t try and open the device before running ghostscript and all that stuff.

Oh, and CUPS has a weird problem when you have only a single remote printer, and no local printers. For some reason, when I try and modify a class, the remote printer doesn’t come up in the list. I could add the remote printer to the class via the command line, however.

HTTP specification

In the HTTP spec it says:

3.3 use of multipart/form-data

The definition of multipart/form-data is included in section 7. A
boundary is selected that does not occur in any of the data. (This
selection is sometimes done probabilisticly.)

Probabilisticly? Who wrote this shit? If you choose a boundary probabilisticly then given enough usage you will almost definitely, at some point in time, pick a boundary which will occur naturally in the data (though one alternative, choosing a boundary deterministically after scanning through the data, is not too appealing either). This sort of thing just shouldn’t be allowed to happen (even if the probability is low) because it can easily be prevented. There are two perfectly suited techniques to avoid the problem that this could cause:

1. Mandate a Content-length header in each part (which obviates the need for a boundary tag anyway) OR
2. Use content transfer encoding (escaping) so that the boundary cannot possibly occur in the encoded content

Neither of these techniques would be particularly difficult to implement or costly in terms of processing time or bandwidth (considering that Content-length for the entire body will generally need to be calculated anyway). The first one seems to be allowed by current standards, but not recommended anywhere and certainly not mandated (and arguably, doesn’t really solve the problem unless the standards are updated to say that it does – since the boundary tag should arguably be recognized wherever it occurs, even if it is partway through a body part according to that body part’s known content length). The second one has the problem that the only defined encoding which would be suitable is base64, and that incurs a 33% bandwidth overhead.

It’s really annoying that this sort of stupid blunder can make it into a standard which is so widely used. At least it seems it can’t lead to any security vulnerabilities (I think) but I pity the poor sucker whose file-upload-via-POST is failing due to a shoddy standard which says it’s ok that a boundary tag could possibly occur within the content.