httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Re: cvs commit: httpd-2.0 STATUS
Date Tue, 28 May 2002 21:34:33 GMT
On Tue, May 28, 2002 at 05:16:57PM -0400, Cliff Woolley wrote:
> On 28 May 2002 jerenkrantz@apache.org wrote:
> 
> >   Cliff can revoke this as a showstopper, but I think this'll get fixed
> >   as soon as I (or someone else) figures out how to return HTTP errors
> >   from a filter.
> 
> As long as somebody's looking at it, I'm perfectly fine with it being
> documented lest we forget about it.

As I mentioned in the release guidelines I posted to the dev site
earlier today, the RM has complete control over showstoppers and
the features that make it in.  So, you don't have to abide by the
pool vote if you aren't comfortable with having it in .37.

If you get a chance, I'd appreciate it if you could look over those
guidelines and see if you see anything you could improve upon.

> Would an ap_bucket_error help you here?

Well, I'm not really sure.  Would the error bucket get sent back to
the caller?

The idea is that we want the 413 to be returned to the client.  Part
of the problem (as I hinted earlier) is that the filters return
apr_status_t codes and ap_discard_request_body returns HTTP status
codes.

A semi-logical solution would be to call ap_die(), but that calls
discard_body() again which calls HTTP_IN which makes us go into an
infinite loop (ap_die() doesn't toss headers_in or clean up the
filter contexts, which I think it should perhaps).

Another solution is to have the input filter write directly to
the output_filters.  That *might* work, too.

Another solution is to return an error bucket and refactor
discard/get_client block to understand the error bucket type.

Regardless, the current code lacks a solid way to return HTTP
error codes to a client from an input filter.  -- justin

Mime
View raw message