Problem with FUJI XEROXApeosPort MultifunctionDevice and the "Expect: 100-continue header"

Duncan McEwan duncan at ecs.vuw.ac.nz
Tue Jan 25 12:51:52 PST 2011


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.

> 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...

Thanks,

Duncan





More information about the cups-devel mailing list