[cups.bugs] [LOW] STR #2411: CONTENT_TYPE may now be set differently in 1.2.11 than in 1.2.10
duncan at mcs.vuw.ac.nz
Thu Jun 7 04:06:57 PDT 2007
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
Our CUPS print server has some queues defined with a destination URI like
I'd be happy to explain what we are trying to achieve with this set up if
required, but that would make this problem report overly long, and I don't
think it is relevant to the problem.
With 1.2.10 and earlier, a backend script for "some-other-printer" would
see a mime content type (in the CONTENT_TYPE environment variable) of
"application/vnd.cups-postscript". After upgrading to 1.2.11 the backend
sees a content type of "application/postscript". This is a problem for us
because our local backend script uses the difference in mime content type
to decide whether a print job was submitted directly to
"some-other-printer" or was forwarded from another queue and modifies its
We think the reason for this change is the patch to "backend/ipp.c" that
fixed STR2349. In particular if the content type is
"application/vnd.cups-postscript", the statement at line 432 will set
send_options to false. That means that later on that content type isn't
passed on to "some-other-printer" in the IPP document-format attribute,
and so (we're guessing here) the receiving IPP server assigns a content
type of "application/postscript" (perhaps by default, or based on analysis
of the incoming data?).
I've made this a "low priority" report because I'm not sure how guaranteed
the content type of "application/vnd.cups-postscript" when an
"application/postscript" document has been processed by a previous cups
filter is. If it's not guaranteed then I guess this bug report can be
closed and we'll have to find another way to do what we want.
As a slightly related aside, we couldn't figure out the rationale for
changing ipp.c's option passing behaviour based on whether or not the
content type matches "application/vnd.cups-". Likewise, even the pre
1.2.11 code altered its behaviour based on whether or not multiple copies
were supported by the printer. The comments seemed to indicate that these
may be attempts to work-around bugs in specific vendor IPP
implementations, but we don't understand why whether or not copies are
supported is a good indication that you are talking to one of those
vendors printers. Any additional insight would be greatly appreciated.
More information about the cups