The signal handler would read the response and handle it. The main thread
would then re-check the state of the transmission, and if the received
message did NOT indicate an error, would continue with the POST operation.
This was fairly simple to implement (at least under Unix...) and would
react quickly in the event of any server failure indication.
Randy
At 10:03 AM 9/29/98 -0700, Brian R Glass wrote:
>Carl Kugler wrote:
>>PRO> "A client MUST NOT expect a response from an IPP server until after
the
>>client has sent the entire response. But a client MAY listen for an error
>>response that an IPP server MAY send before it receives all the data. In
this
>>case a client, if chunking the data, can send a premature zero-length
chunk to
>>end the request before sending all the data. If the request is blocked
for some
>>reason, a client MAY determine the reason by opening another connection to
>>query the server."
>>The ietf-http-v11-spec says that the client MAY expect a response from an
HTTP
>>server before the client has sent the entire request, IF it announces this
>>intention with the "Expect: 100-Continue" HTTP header. "The purpose of the
>>100 (Continue) status (see section 10.1.1) is to allow an end-client that is
>>sending a request message with a request body to determine if the origin
server
>>is willing to accept the request (based on the request headers) before the
>>client sends the request body. In some cases, it might either be
inappropriate or
>>highly inefficient for the client to send the body if the server will reject
>>the message without looking at the body." I don't see why IPP should
prohibit
>>this.
>
>I agree. In fact, we may want to suggest that clients SHOULD
>be listening to the port while sending the body of the request.
>This would be usefull if the job gets canceled while transmitting
>the body, say by an administrator. If the printer implementation
>quits pulling data off of the network and sends the response, the
>client may appear to be 'hung' until all the data is sent. In
>fact, this was the behavior I noticed from some clients I saw at
>the Bake Off. The cleanest way to handle this is for the printer
>implementation to send a reply that the job was canceled (through
>job-status?) and then let the client close down the connection.
>If the client does not close down the connection then the server
>should time out and reset the connection. If this happens then
>the client may loose the response from the server. Thoughts
>anyone?
>
>regards,
>
>Brian
>--
>=============================================================
>Brian R. Glass Tektronix, Inc
> 26600 SW Parkway
>Color Printing & Imaging Division PO Box 1000
> MS 60-368
>mailto:Brian.Glass@tek.com Wilsonville, OR 97070-1000
>http://www.tek.com/Color_Printers (503) 685-2456
>=============================================================
>