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

[Michael Sweet]

On Jan 24, 2011, at 8:19 PM, Duncan McEwan wrote:
>> ...
>> 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...)
> 
> OK - as I said, I'm not familiar with all the details of the HTTP and IPP protocols and so I'm quite likely missing something here.  But it seems to me that the origin server *should have* received a complete request body since my tcpdump packet trace shows the HTTP request header and IPP request were both transmitted by CUPS without waiting for the 100-continue response.

The strategy CUPS uses is to periodically check for a response as the request and request body are sent.  The 1 second wait comes after the IPP message is sent but before any document data is sent.

In any case, if the printer sends a successful response before getting the entire message body, it isn't following RFC 2616...

That said...

> ...
> If this is the printers fault, would an acceptable workaround be a configuration
> option to tell CUPS not to expect the "100 Continue" response for certain
> (broken) printers?


CUPS currently doesn't offer a configurable option for this, but does go into a "no expect" mode if the printer fails to respond the first time we send a request.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cups.org/pipermail/cups/attachments/20110124/81a70aba/attachment.html>