cupsDoRequest usually fails when reusing the http_t* connection between the printer.

[xiaowen581]

After some investigation, several unclear issues were discovered:

1. After a cupsDoRequest, the socket connection was closed (a TCP four-way termination handshake was observed), even though HTTP_KEEPALIVE_ON was set using httpSetKeepAlive and last response had a "Connection: keep-alive".
2. In cupsSendRequest, reconnect if the last response had a "Connection: close". However, because the last response had a "Connection: keep-alive", there was no reconnection made.

I cannot provide the debug log because once the debug log is enabled, the issue cannot be reproduced. The reason is that when data is sent to the printer through a socket that has been closed, the printer sends an RST packet. Enabling the debug log affects the timing of the RST packet processing.

When off the debug log, RST happens after the [IPP Request] packet , which lead to IPP status 1280

If open the debug log, RST happens before the [IPP Request] packet , which lead to a retry in cupsDoIORequest, and then cupsDoRequest will succeed.

In my app, I can perform a retry after a cupsDoRequest failure, but I think the httpReconnect2 logic in cupsSendRequest and the keep_alive in _http_s seems not to be well thought out.

[michaelrsweet]

In my app, I can perform a retry after a cupsDoRequest failure, but I think the httpReconnect2 logic in cupsSendRequest and the keep_alive in _http_s seems not to be well thought out.

A printer that closes the HTTP connection after processing one IPP request successfully and doesn't include the "Connection: close" header is not conformant - what printer are you talking to?

The code to send the HTTP POST request does try to reconnect if it detects the connection is closed but due to the nature of the BSD sockets API it is possible for that failure to not be detected until after the request is sent. Your observation that debug logging changes the behavior confirms this issue...

Since we don't want cupsSendRequest to retry indefinitely (that could cause problems), we return an error and expect the caller to retry as necessary/desired.

[xiaowen581]

A printer that closes the HTTP connection after processing one IPP request successfully and doesn't include the "Connection: close" header is not conformant - what printer are you talking to?

Ricoh IM 4000 PS3, a shared company printer. I suspect it may be due to a limit on the number of connections or some other reason that caused the socket to close prematurely.

The last response from the printer contained a keep-alive, and then the printer sent [FIN, ACK] after only 1.1 seconds. It seems to be a printer issue.

The code to send the HTTP POST request does try to reconnect if it detects the connection is closed but due to the nature of the BSD sockets API it is possible for that failure to not be detected until after the request is sent. Your observation that debug logging changes the behavior confirms this issue...
Since we don't want cupsSendRequest to retry indefinitely (that could cause problems), we return an error and expect the caller to retry as necessary/desired.

Thank you for your explanation.