[cups.bugs] [MOD] STR #2683: Printers using HTTP 1.0/IPP will not print with the ipp backend "ipp backend failed"

[Martin Suefke]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

The problem appeared with a Lexmark T620dn printer. This is a PostScript
Level 3 network printer with duplex option.
It would print with CUPS 1.1.20 but not with 1.2.4, 1.2.7 or 1.3.5 when
using ipp. It could print with socket protocol using any of the above
version but not with ipp.

The error on the local CUPS admin interface is "backend/ipp failed"
The diagnostic obtained from wireshark when operating a looked similar to
that given in (STR #1946). libpcap captures can be provided on request.
The error is to any degree comparable to that in STR #1946

The solution is the HTTP protocol underlaying the IPP protocol.
All answers from the printer contain with "HTTP 1.0". Cups on the other
side always uses "HTTP 1.1"

This implies that the printer does not know anything about the 
HTTP 1.1 status "HTTP 100-continue" which in turn causes the ipp backend
to stall because ipp.c is waiting for that particular status message

This message won't come from a printer that does only HTTP 1.0,
because 1xx messages are only defined in HTTP 1.1 and later

Solution: Just send print files if HTTP version 1.0 was encountered
earlier and a HTTP_CONTINUE would be expected before actually sending
the files.

It can be assumed that this fix also resolves (STR #1946), thus applying
to at least Lexmark E332n, too. 

A last word on STR #1946: There it said that ipp support was broken on the
printer. That is not true. This printer (Lexmark T620 in this case) works
using Windows or Solaris standard lpd (I tried both) with
ipp://printer:631 . The printer only implements HTTP 1.0 which is clearly
visible from the dumps provided with STR #1946, so CUPS assumption that
the printer should be treated like an HTTP 1.1 printer is just dead wrong.
That printer is not required to give a HTTP 1.1 like  status "HTTP
100-continue" ever, as "HTTP 100" is *optional* in the HTTP 1.0
specification as per
http://www.w3.org/Protocols/HTTP/1.0/spec.html#Code1xx
And indeed, the printer only tags it's ipp replies with "HTTP 1.0"

The attached patch is a rather crude hack that treats "no status received"
like "HTTP_CONTINUE", if a http->version 1.0 was encountered earlier in the
printers replies. It assumes that the printer will react to the first query
"Get Printer Attributes" properly even though that is made with HTTP 1.1.
Note that this request is not segmented in between with "expect:
100-continue" fields. The reply to "Get Printer Attributes" sets the
http->version in http.c which seems to be retained throughout the printing
session (i.e. for the remaining ipp run time). Functions like
"httpClearField" luckily don't reset the version information. ipp.c then
skips the checks for "HTTP_CONTINUE" received.

It would be nice to see that included in future versions. 
These printers are cheap nowadays (old machines from lease returns). Most
of them are very usable (even in household environments) as they were made
for 100.000's of pages and a lot of them have page counts in the lower
200-300.000 sector, leaving years of life to come.
That is why it would be nice to have support for them.

Maybe an option can be made like "http=1.0" similar to like
ipp://printer:631?version=1.0 for using ipp 1.0 instead of 1.1
However, version=1.0 does not change anything about the HTTP behavior.
Unfortunately that is well beyond my capabilities.

I made a patch that compliles (for me: OS=Solaris Express Developer 9/07,
gcc 3.4.3) cleanly against 1.3.5 sources. Also see the patched
CHANGES.txt. Patch like this: untar cups-1.3.5-source.tar; cd cups-1.3.5;
patch -p0 </path/to/patch;

Link: http://www.cups.org/str.php?L2683
Version: 1.3.5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_cups_1.3.5_for_LexmarkT620_v003
Type: application/octet-stream
Size: 11166 bytes
Desc: not available
URL: <https://lists.cups.org/pipermail/cups/attachments/20080123/72126d0c/attachment.obj>