client 1.2.0 to 1.1.2x server over IPP: SendError: 5 code=400 Bad Request

Fixed in CUPS svn? http://www.easysw.com/~mike/cups/str.php?L1407

Comparing our source with svn, the fix mentioned in the above url isn't in our CUPS. I'm building from svn to see what happens...

Still no workee in svn. Strace shows the following header bing sent:
POST /printers/samsung HTTP/1.1
Content-Length: 14724
Content-Type: application/ipp
Host: clerk
User-Agent: CUPS/1.2rc3
Expect: 100-continue

then

sendto(3, "\1\1\0\2\0\0\0\1\1G\0\22attributes-charset\0\5"..., 250, 0, NULL, 0) = 250

then

recvfrom(3, "HTTP/1.1 400 Bad Request\r\nDate: "..., 2048, 0, NULL, NULL) = 353

Comparing the above strace to one generated using lp on the server...

send(3, "\1G\0\22attributes-charset\0\niso-8859"..., 34, 0) = 34

which looks quite a bit different...
and these headers...
send(3, "H\0\33attributes-natural-language\0\5"..., 37, 0) = 37
send(3, "E\0\vprinter-uri\0$ipp://localhost:"..., 52, 0) = 52
send(3, "B\0\24requesting-user-name\0\10trappis"..., 33, 0) = 33
send(3, "B\0\10job-name\0\3foo", 16, 0) = 16
send(3, "I\0\17document-format\0\30application/"..., 44, 0) = 44
send(3, "\2B\0\njob-sheets\0\4noneB\0\0\0\4none", 29, 0) = 29

which apparently aren't sent from Ubuntu's lp. Also notice there's no Expect: 100-continue header here.

With a custom python ipp implementation (that works) I can reproduce this behavior by omitting the attributes-natural-language header.

CUPS STR bug: http://www.cups.org/str.php?L1605+P0+S-2+C0+I0+E0+Q

Since I seem to be the only one experiencing this problem, and since the same happens when I compile cups from upstream svn, and since the response from upstream can be paraphrased as "no, stupid", I'm going to write this off as a mysterious configuration issue and move the printers from the printserver back to the ubuntu box and close this bug. I'll keep an eye out for a reason to reopen it and dupe another bug against it.

Hi Rocco, I don't think your questions were stupid. Actually, we may have a confirmartion for your bug. Could you check bug 42513 and tell us if it is the same issue that you have? Thank you very much in advance.