On Thu, 2002-09-19 at 09:07, [EMAIL PROTECTED] wrote:
> yep, requests are always logged in order.
Thanks. Back to the code :-)
Bojan
On 19 Sep 2002, Bojan Smojver wrote:
> On Thu, 2002-09-19 at 07:59, [EMAIL PROTECTED] wrote:
>
> > Great, now one more change. :-)
> >
> > Don't add the fields to the structure. The conn_Rec has a vector for
> > modules to add data to. Create a log_config structure, and add the fields
> > th
On Thu, 2002-09-19 at 07:59, [EMAIL PROTECTED] wrote:
> Great, now one more change. :-)
>
> Don't add the fields to the structure. The conn_Rec has a vector for
> modules to add data to. Create a log_config structure, and add the fields
> there. This allows the core structures to remain as t
On 19 Sep 2002, Bojan Smojver wrote:
> On Thu, 2002-09-19 at 00:05, [EMAIL PROTECTED] wrote:
>
> > The easiest way, would be to put the filters in mod_log_config, and have
> > that module save the information in a connection_rec vector.
>
> OK, I think I roughly understand what is the plan:
>
On Thu, 2002-09-19 at 00:05, [EMAIL PROTECTED] wrote:
> The easiest way, would be to put the filters in mod_log_config, and have
> that module save the information in a connection_rec vector.
OK, I think I roughly understand what is the plan:
- introduce c->bytes_in and c->bytes_out (c is conn_
On Wed, 18 Sep 2002, Bojan Smojver wrote:
> Quoting [EMAIL PROTECTED]:
>
> > 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 se
There is another possibility to fix this, and that's within the module
itself (I've tested it and it works):
--
static void logio_create_req(request_rec *r) {
ap_filter_t *f;
conn_rec *c = r->connection;
/* Tie connection filters with r
Quoting Brian Pane <[EMAIL PROTECTED]>:
> 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.
Counting in the request based filter is easy, but there are a few problems:
- request based input
On Tue, 2002-09-17 at 21:46, Bojan Smojver wrote:
> Quoting [EMAIL PROTECTED]:
>
> > 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
Quoting [EMAIL PROTECTED]:
> 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
On Wed, 18 Sep 2002, Bojan Smojver wrote:
> I understand. But isn't the ap_read_request HTTP specific given it's creating
> the request and all? In other words, if protocol is HTTP, we let connection
> filter know about the request. If not, we don't. That to me sounds exactly the
> same as your s
Quoting Ryan Morgan <[EMAIL PROTECTED]>:
> I would tend to agree with Ryan here, it should not be assumed that the
> request_rec will be available in the core_output_filter.
I wasn't planning on making any changes to core_output_filter that would make it
depend on f->r being set. The whole thing
I understand. But isn't the ap_read_request HTTP specific given it's creating
the request and all? In other words, if protocol is HTTP, we let connection
filter know about the request. If not, we don't. That to me sounds exactly the
same as your suggestion.
I must be missing something...
Bojan
I would tend to agree with Ryan here, it should not be assumed that the
request_rec will be available in the core_output_filter. One possible
solution would be to have c->bytes_in and c->bytes_out, then have identical
fields in the request_rec that would be updated upon the completion of the
req
You don't want to do this. A connection based filter is connection
oriented. By definition, it has no concept of a request. While this
might make sense for HTTP, other protocol modules will have a much harder
time with this change.
Ryan
On 18 Sep 2002, Bojan Smojver wrote:
> Justin,
>
> Af
Quoting Justin Erenkrantz <[EMAIL PROTECTED]>:
> 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;
> }
What was that book again... K&R, The C Pr
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
OOPS, forgot the variable itself...
Bojan
On Wed, 2002-09-18 at 07:36, 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 loo
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 Se
19 matches
Mail list logo
