On Wed, Sep 18, 2002 at 07:36:00AM +1000, Bojan Smojver wrote:
> Justin,
>
> After mucking around a bit with what you suggested, this seemed like the
> straightforward thing to do. Not sure how things would work on internal
> redirects etc. Can you please have a look. I'm sure it's naive, but so
> am I (for now :-)
>
> Bojan
> --- httpd-2.0-vanilla/server/protocol.c Fri Sep 6 16:01:19 2002
> +++ httpd-2.0/server/protocol.c Wed Sep 18 07:32:37 2002
> @@ -895,6 +895,15 @@
> r->connection = conn;
> r->server = conn->base_server;
>
> + /* Update the request in connection filters */
> + f = conn->input_filters;
> + for (; f; f = f->next)
> + f->r = r;
> +
> + f = conn->output_filters;
> + for (; f; f = f->next)
> + f->r = r;
> +
Well, I'd do (plus the declaration of f in your later post):
for (f = conn->input_filters; f; f = f->next) {
f->r = r;
}
for (f = conn->output_filters; f; f = f->next) {
f->r = r;
}
Now, the question is whether anyone has any major qualms with this.
Basically, it now allows connection filters some access to the
current request_rec (as defined by the protocol module).
Internal redirects would be handled by the update_r_in_filters func
in http_request.c (which is equivalent to this for statement - hmm,
I forsee ap_update_filters in our future), so that should be fine.
The only potential problem I forsee is whether the input bytes could
be logged on one request, and the output on another. Therefore, we
might want to walk r->prev and add the totals to get our real bytes
read and sent. Oooh, internal_internal_redirect copies the
r->read_length to the new request, so I think we're fine.
For the logging case, I think this makes a lot of sense as it lets
us simplify how we log. -- justin
