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

[Michael Sweet]

On Jan 25, 2011, at 12:51 PM, Duncan McEwan wrote:

> Hi Michael,
> 
> Once again, thanks for the quick response...
> 
>> In any case, if the printer sends a successful response before getting
>> the entire message body, it isn't following RFC 2616...
> 
> Yep - I understand that.  So can you explain why you think the printer hasn't received the entire message body in this case, when from my tcpdump I can clearly see that both the HTTP header and the IPP Get-Printer-Attributes requests have been sent before the printer responds with the HTTP OK message.

In this case I didn't see this particular problem for the Get-Printer-Attributes, but it looked like the printer responded before receiving all of the document data in the Print-Job request.

>> 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.
> 
> Yes - that was one of the parts of the code that I saw and understood!
> 
> But what about the rest of my email, where I described the sequence of events we were seeing in the log file?  Especially the bit about CUPS seeming to be reading bogus data from a previously received buffered packet, which is the cause of the two minute delayed start of printing.
> 
> I did theorize that the bogus data might be related to the issue that you addressed in STR #3778, though as I explained, I couldn't understand what the existing code or your fix was trying to do well enough to confirm that.  I'm more than happy to be told that my theory is incorrect, though if so, I'd like to know the actual cause!
> 
> I understand that you are busy and aren't able to spend lots of time investigating a problem that (apparently) no one else is experiencing.  But I was hoping that your familiarization with the code would be enough to be able to confirm/discount my theory without too much effort.  If that isn't the case let me know as I'm quite willing to have another look at the code to try to work it out myself...

I think right now the best testing path would be to build the current trunk code on your system and test against the printer - run "make test" to build and run a test server separate from your production one...

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair