[cups.bugs] Problem with FUJI XEROX ApeosPort Multifunction Device and the "Expect: 100-continue header"

[Michael Sweet]

Thanks for the long post - comments inline...

On Jan 17, 2011, at 8:45 PM, Duncan McEwan wrote:
> ...
> I am far from an expert in the IPP and/or HTTP protocols, but I did have a quick read of rfc2616 and found the following passage:
> 
>    An origin server MAY omit a 100 (Continue) response if it has
>    already received some or all of the request body for the
>    corresponding request.

Correct, but the origin server cannot respond with a *successful* status until it has received *all* of the request body (since successful statuses allow for Keep-Alive and pipelining; failure status codes cause the connection to close...)

> ...
> As an aside, I'm not sure why CUPS is bothering with the "Expect: 100-continue" header in this case, as the Get-Printer-Attributes request is not large.  I can see that it might be useful to include it in the "Print-Job" request if the file to be printed is big.

The main reason is to get the "I need authentication" or "I need to upgrade to TLS" response before sending any of the request data.

> I did search old forum postings and found STR #1407, in which it is said:
> 
>    The strategy we are using in CUPS 1.2 is to send the Expect header but
>    only wait 1 second for the 100-continue response. If we don't get a
>    response, we continue as if we got the response...
> 
> I think the problem here may be that instead of getting no response and therefore continuing as if one had been received, CUPS gets the "HTTP/1.1 200 OK", which might confuse it (though I haven't had a careful look at the relevant code to see if this is indeed the case).

Nope, the code basically accepts any status response; if no response has been received we wait up to 1 second to get one.

> While investigating this issue, I noticed something that is most likely not at all related to the main problem described above.  In the tcpdump trace wireshark flagged some "Malformed" IPP Request packets.  I believe these are related to the "cupsGetResponse: Finishing chunked POST..." messages in the debug trace.  The odd thing is that CUPS doesn't seem to be sending the preceeding requests using the chunked encoding format, which is perhaps what is causing wireshark to flag those packets as being malformed?

Hmm, yes.  This is definitely a bug, and one worth reporting here:

    http://www.cups.org/str.php

Thanks!

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair