Re: clientReplyContext::replyStatus and proxy_keepalive
On 02/07/2007 05:42 PM, Alex Rousskov wrote:
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?
Does anybody know the answer to the above? It has been bothering me for
many years, in various contexts. Any clues?
Thank you,
Alex
Re: clientReplyContext::replyStatus and proxy_keepalive
On Mon, 28 Feb 2011 14:25:10 -0700, Alex Rousskov wrote:
On 02/07/2007 05:42 PM, Alex Rousskov wrote:
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?
Does anybody know the answer to the above? It has been bothering me
for
many years, in various contexts. Any clues?
Thank you,
Alex
Looks to me like a simple tri-state result of
success/fail-incomplete/fail-error was intended but somewhere along the
line got abused and broken.
IMHO that status should actually have a five-state:
INCOMPLETE (still processing data)
COMPLETE_SUCCESS (may keepalive, maybe cache, object fully received),
COMPLETE_UNPLANNED_END, (must close, maybe cache as a range, object
is usable but probably incomplete),
COMPLETE_FAIL (error responses generated by Squid, may keepalive, may
cache)
FAIL_ERROR (fubar, abort, must close, must not affect cache)
with keep-alive and cacheability as possible results of the status, not
determiners.
Amos
clientReplyContext::replyStatus and proxy_keepalive
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.
Re: clientReplyContext::replyStatus and proxy_keepalive
On Wed, 2007-02-07 at 17:42 -0700, Alex Rousskov wrote: Hello, If you understand clientReplyContext::replyStatus, please see if you can help me with the following problem. ... 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, I'll page this in and peek at it after work today - in 4-5 hours. Cheers, Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
