Hello,
If you understand clientReplyContext::replyStatus, please see if you
can help me with the following problem.
Background: I am making aborted POSTs to work with the new BodyPipe.
Under certain ICAP failure conditions, the client side needs to produce
an error response. We did not have any code for that case.
I found disabled "#if ICAP_HARD_ERROR" code inside
ClientHttpRequest::abortAdapting, removed the yet-unsupported errno
argument, and moved the code outside the if-statement. That wonderful,
albeit mysterious, piece if code seems to produce an error just fine.
The error is sometimes generated before the entire POST body is read and
discarded.
Problem: The following piece of client_side_reply code appears to be
sometimes confused by the client-side produced error and/or my other
bugs. It returns STREAM_UNPLANNED_COMPLETE, causing various problems on
the client_request side (e.g., entering "closing" state twice).
> clientStream_status_t
> clientReplyContext::replyStatus()
> {
> ...
> if (!done) {
> debug(88, 5) ("clientReplyStatus: closing, !done, but read 0 bytes\n
> return STREAM_FAILED;
> }
>
> if (!http->gotEnough()) {
> debug(88, 5) ("clientReplyStatus: client didn't get all it expected\
> return STREAM_UNPLANNED_COMPLETE;
> }
>
> if (http->request->flags.proxy_keepalive) {
> debug(88, 5) ("clientReplyStatus: stream complete and can keepalive\
> return STREAM_COMPLETE;
> }
>
> debug(88, 5) ("clientReplyStatus: stream was not expected to complete!\n
> return STREAM_UNPLANNED_COMPLETE;
Could somebody please explain the logic here? Specifically, I do not
understand why proxy_keepalive flag is required to get a STREAM_COMPLETE
result. I am getting STREAM_UNPLANNED_COMPLETE (from the last return
statement) because the request apparently does not have that flag set.
What does it mean to have a "complete stream" and why do I need a
proxy_keepalive flag with that?
A related question: Is replyStatus() expected to work correctly when the
connection is in a closing state?
Thank you,
Alex.
Received on Wed Feb 07 2007 - 17:42:24 MST
This archive was generated by hypermail pre-2.1.9 : Thu Mar 01 2007 - 12:00:02 MST