On Thu, 2002-10-17 at 00:36, William A. Rowe, Jr. wrote:
> At 02:10 AM 10/16/2002, Bojan Smojver wrote:
>
> >Coming back to what William is proposing, the three pool approach... I'm
> >guessing that with Response put in-between Connection and Request, the Response
>will store responses for multi
At 02:10 AM 10/16/2002, Bojan Smojver wrote:
>Coming back to what William is proposing, the three pool approach... I'm
>guessing that with Response put in-between Connection and Request, the Response will
>store responses for multiple requests, right?
No, I'm suggesting a single response pool f
On Wed, 2002-10-16 at 17:54, Brian Pane wrote:
> I think you could achieve this result by appending a bucket of type
> apr_bucket_flush to the output brigade. I think that would be a
> reasonable workaround for 2.0.
This is what I wanted to do initially:
---
Quoting David Burry <[EMAIL PROTECTED]>:
> I know that I'm ultimately wanting to log bytes per request pretty
> accurately to add up and tell if the whole file was transferred or not even
> if it was broken up into several byte range requests. I have given up on
> the possibility of this happeni
Quoting Brian Pane <[EMAIL PROTECTED]>:
> I think you could achieve this result by appending a bucket of type
> apr_bucket_flush to the output brigade. I think that would be a
> reasonable workaround for 2.0.
Cool, thanks. This should be easy - I can simply do it in mod_logio's output
filter, w
I know that I'm ultimately wanting to log bytes per request pretty
accurately to add up and tell if the whole file was transferred or not even
if it was broken up into several byte range requests. I have given up on
the possibility of this happening in 2.0 for a long time to come due to the
archi
On Wed, 2002-10-16 at 00:10, Bojan Smojver wrote:
> Coming back to what William is proposing, the three pool approach... I'm
> guessing that with Response put in-between Connection and Request, the Response
> will store responses for multiple requests, right? Then, once the core-filter is
> done
Quoting Brian Pane <[EMAIL PROTECTED]>:
> Yes, that scenario is possible. And even without multiple virtual
> hosts, attributing bytes to the wrong request will make the logging
> a lot less useful to anyone who's trying to use the bytes_sent data
> for debugging or planning purposes. If we can
On Tue, 2002-10-15 at 23:07, Bojan Smojver wrote:
> > The MMN bump in this case is no problem. Your patch just adds
> > fields at the end of the structure. It's backward compatible,
> > so it only needs an increase in the MMN minor number, not the
> > major number. If the patch added fields in
Quoting Brian Pane <[EMAIL PROTECTED]>:
> On Tue, 2002-10-15 at 22:09, Bojan Smojver wrote:
> > I have submitted the patch along those lines a few days back, which also
> > includes an MMN bump. In the light of the latest discussions on the list,
> it
> > seems that a patch like that is not being
On 15 Oct 2002, Brian Pane wrote:
> major number. If the patch added fields in the middle of the
> struct, thus breaking binary compatibility, then it would be
> a problem.
Even adding at the end can break binary compat, since sizeof(conn_rec)
changes, so you might have 3rd party code that allo
On Tue, 2002-10-15 at 22:09, Bojan Smojver wrote:
> I have submitted the patch along those lines a few days back, which also
> includes an MMN bump. In the light of the latest discussions on the list, it
> seems that a patch like that is not being looked at favourably by many people :-(
The MMN b
I have submitted the patch along those lines a few days back, which also
includes an MMN bump. In the light of the latest discussions on the list, it
seems that a patch like that is not being looked at favourably by many people :-(
Do you want me to rework that patch so it uses a privata data str
13 matches
Mail list logo
