httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: return value of a filter
Date Sun, 27 Aug 2000 14:24:56 GMT
Manoj Kasichainula <manoj@io.com> writes:

> I do agree that "bytes consumed" by itself is meaningless, especially
> in the case where you're passing buckets of indeterminate size (like
> file or pipe). I could think it's reasonable to want to know how many
> buckets were consumed out of the brigade, and where in a bucket you
> died, for error handling.
> 
> "Transmission failed in %s, byte %n", failed_bucket, num_bytes

I guess that if every filter had this type of trace logic, you might
be able to relate the problem to a specific part of the content
(assuming that it isn't the usual error scenario where the client
drops the connection).

I don't think this info is useful enough to require every filter to
report it.  I think that the most useful traces wouldn't need that
information... 

I can see a specific message by certain types of filters explaining
why they signalled an error...

example 1: the core filter reports that it got ECONNABORTED writing to
the network; if the core filter maintains the BO_BYTECOUNT info, it
can report that in the trace

example 2: a charset translator could complain about an invalid
character sequence (usually indicating a misconfiguration); it could
dump a few bytes of its input in the trace message

Hmmm...
-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message