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.
