httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: Output filter behaviour
Date Tue, 11 Jun 2002 12:02:18 GMT
> Hi guys,
> 
> How do we handle errors in an output filter if the headers have
already
> been
> sent?

You can't.  You must buffer all data until you know whether you will
have an error or not.  This should make sense, once the first block of
data has been sent to the next filter, you have lost all control of the
data, and the headers may have been sent to the client already.  Once
the headers have been sent to the client, you can't return an error at
all.

> 
> Suppose:
> static apr_status myfilter( ... )
> {
>     if( !ctx )
>     {
>        ....
>     }
> 
>     if( ctx->state++ == 0 )
>     {
>         ....
>     }
>     else
>     {
>         /* headers already sent??? */
>         ...
>         ERROR DETECTED HERE!!!
>     }
> 
>     return ap_pass_brigade( f->next, bb );
> }
> 
> What will happen if I 'return APR_EGENERAL' when the error is
detected?
> What
> is the right thing to do?

I don't think anything will happen, except that the response will be
terminated early.  BTW, the proper way to report an error from within a
filter is to create an error bucket that specifies the HTTP error code.

> Also, how does http_header filter calculate 'content-length'. Aren't
> output
> filters feeding data to the client chunks by chunks? So how does it
know
> how
> big it will be?

The Content-Length filter calculates the content-length, not the
http_header.  It has a lot of logic to skip calculating the C-L, unless
it absolutely has to.  Remember, that we can use chunked encoding or, if
it isn't a keepalive request, we can just terminate the connection, so
we don't always need a C-L.  The handler can also specify the C-L.  If a
filter modifies the data, then it has the responsibility to remove the
C-L from the response headers.

Ryan



Mime
View raw message