httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: [PATCH] checking for failures encountered by core_output_filter
Date Mon, 04 Nov 2002 16:07:40 GMT
Justin Erenkrantz <> writes:

> >> I don't buy that logic at all.  Why should we be returning
> >> APR_SUCCESS here?  We want to signal an error, so that the filters
> >> stop what they are doing and exit.
> >
> > Talk to Ryan :)
> Well, he ain't here no more.  Just us folks.  Do you (or anyone else)
> see a reason why we shouldn't change this?

interpret "Talk to Ryan" as "I can't justify the current behavior" :)

We should make the change to return an APR error code here.

> > I'm kinda stuck thinking that the philosophy should be that we log
> > whatever was written to the client in the status line, but there are
> > some implementation details with that one.
> How do we differentiate between a 200 that all the data was sent for
> and a 200 where the client aborted?  If someone looked at the access
> logs, they would see that the transmitted length wasn't correct in the
> aborted case.  Perhaps that was Ryan's initial motivation - did he
> want the length to be what we wanted to send not what we actually
> sent?  (mod_logio is bringing up some of these concerns as well.)
> I guess I'd like to see some notation in access log that indicates,
> "Hey, we know we didn't send everything, but that's because they left
> in the middle."  Yes, it also might be noted in the error log, but I
> gotta believe it's goodness to have tools looking at just the access
> logs know that the client aborted.

FWIW, this is what happens with 1.3 when the client drops the
connection before reading the entire response.  In this case, the
client read several bytes of a 1MB response (though the client TCP
accepted a lot more).

  [Mon Nov  4 10:31:22 2002] [info] [client] (32)Broken pipe: 
  client stopped connection before send mmap completed - - [04/Nov/2002:10:31:22 -0500] "GET /bigfile.html" 200 65536

Even though Apache could have noticed that it sent only 64K out of
1MB, it still logged 200.  The 64K isn't even an indication of how
much the client really read.  It is simply how much TCP was willing to
buffer.  Also, I suspect that we can hit the first indication of a
dropped connection after the previous response has been noted in the

I'm not sure what promises we can make about what is in the access

> > One issue with that is that the filter that encounters the error
> > really should do the logging so that the most specific information
> > is available.  If some other code also logs less-specific info,
> > then it is all for naught.
> Makes sense.  So, core_output_filter should be calling
> ap_log_rerror. Hmm.  Does it have access to the request_rec?  Didn't
> we change that? Or, was I vetoed on that?  -- justin

I don't recall that conversation.  Regardless, I wonder how 
core_output_filter could know the r associated with a particular

Jeff Trawick |
Born in Roswell... married an alien...

View raw message