httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: dropping a connection abruptly
Date Tue, 24 Oct 2006 16:56:07 GMT
On Tuesday 24 October 2006 17:25, Brian McQueen wrote:

> 1) a input filter that creates an eos bucket and passes it on as the
> brigade 2) mark the connection as aborted
> 3) set keepalive to AP_CONN_CLOSE
> 4) flush the req
> 5) flush the connection
> 6) finalize the protocol
> 7) discard the request body
> I bet the order of these isn't quite right, but this batch of things
> shuts it down promptly upon return.

Looks like you've made a good start on it.  I'll be interested to hear
how this works out with real clients.  This set me thinking:

(1) You're really working at the network level.  That sits uneasily
with a request-level filter.
(2) But you need the protocol, because that's what tells you you're
going to reject the request based on length.

So maybe this input filter isn't what you want.

> I thought I'd add something about why this entire procedure is bad.
> In addition to the HTTP compliance issue that I mentioned before,

On which you have reassuring feedback from Roy Fielding, the man
whose name heads the HTTP spec:-)

> fiddling with the socket is bad because module writers should assume
> they are writing a module that can get along with other unspecifed
> modules.  Having a module get to the socket and mess with the
> connection will alter the basic environment that module writers
> assume.  Modules that follow may not be designed to run well with a
> dead socket.  It is usually not part of a module writer's concern.

That's right.

Basically you need to break this off after reading the headers but
before reading the entire body, and bearing in mind you do want to
get a response back to the client.  So what you probably want to do
is move checking of content-length to a header-parser hook (or
even a post-read-request if the maximum size doesn't need to be 
configurable).  That can then return 413 to generate a standard
error document.  OK, now that's the easy bit dealt with.

Now, since you're detecting the condition in an ordinary hook,
you can move your filter - which is doing basically the right thing -
right up the chain to the network level.  It would either be something
close to a clone of the core input filter, but with additional checks
for a flag your hook has set, or sit immediately behind the core filter.
On encountering that flag, it winds up gracefully.  And the key point is: 
you're now in the right place to be playing with the socket.

Details left as an exercise for the reader, 'cos I haven't exactly
worked through it :-)

Nick Kew

Application Development with Apache - the Apache Modules Book

View raw message