httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: [PATCH]: Update request in connection based filters
Date Wed, 18 Sep 2002 04:51:59 GMT
On Tue, 2002-09-17 at 21:46, Bojan Smojver wrote:
> Quoting rbb@apache.org:
> 
> > The problem is that the filters aren't HTTP specific.  If you make this
> > change, then the filters will be written to take advantage of the f->r
> > field in connection level filters.  Since that field doesn't make sense in
> > non-HTTP requests, modifying the filter_rec so that it is there is a
> > mistake.
> > 
> > Think about it this way.  If you add the request_rec to the
> > core_output_filter, and that filter is modified to use it, then all
> > protocol modules must ensure that the request_rec is added to the filter,
> > even if it doesn't make sense.
> > 
> > If you make it optional to put the request_rec in the filter_rec, then you
> > will be making it much harder to write filters.
> 
> OK, I think I understand now what you're trying to say. Things can go wrong if
> important fields can be NULL when you want them to be non-NULL and vice versa. I
> reckon that good documentation on the matter would help developers understand
> that they cannot depend on f->r being set for some protocols, which would
> eliminate confusion. But, this is the first ever filter that I'm writing and
> it's awfully simple, so I could be dead wrong.

The real problem is that "r" is HTTP-specific.  If we were designing
the server from scratch, I suppose we could introduce a protocol
independent "generic request structure" for use in any protocol that
had some sort of discrete request, and make that accessible within
the connection-level filters.  But for historical reasons, the
request_rec is HTTP-specific.

However, if you can do the byte counting in a request-level filter
(right after the HTTP output filter?), that should enable you to
bypass the problem.

Brian




Mime
View raw message