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
Quoting Brian Pane <[EMAIL PROTECTED]>:
> The one problem I see is that, because the response data might
> not be written until after the request has been logged--in the
> case of a keep-alive request--the bytes_out field will need to
> be updated *before* setting aside any output in core_output_
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
Bojan Smojver wrote:
>I'm proposing to add two extra fields to request_rec structure:
>
>apr_off_t bytes_in
>apr_off_t bytes_out
>
>These babies would be used to record the number of bytes received and sent (on
>the wire) per each request. I'm writing a little filter module (with a lot of
>help
I'm proposing to add two extra fields to request_rec structure:
apr_off_t bytes_in
apr_off_t bytes_out
These babies would be used to record the number of bytes received and sent (on
the wire) per each request. I'm writing a little filter module (with a lot of
help from Justin :-), to do the act
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
[EMAIL PROTECTED] wrote:
>__pthread_alt_unlock() loops through a list of threads that are blocked on a
>mutex to find the thread with the highest priority. I don't know which mutex
>this is; I'm guessing it's the one associated with worker's condition variable.
>The ironic thing is that for http
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
> Sent: 17 September 2002 20:57
> >*sigh* Ofcourse you are right. So, what do we do, stick with 2.0.41 or retag
> >APACHE_2_0_42 to be the same as APACHE_2_0_41 and reroll?
>
> Don't be silly, this is an alpha candidate.
>
> Before it mo
On Tue, Sep 17, 2002 at 09:09:38PM +0200, Sander Striker wrote:
>...
> > > Just on the basic premise that the tarball has been released. At this
> > > point, it is available for users. If we are going to create new tarballs,
> > > then must have a new name.
Nope. The contents are the same. We'r
At 01:59 PM 9/17/2002, Sander Striker wrote:
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: 17 September 2002 20:44
>
> >>> I would also recommend a new tarball with the timestamp tweaked.
> Something
> >>> like so:
> >>>
> >>> $ tar xzf httpd-tar.gz
> >>> $ touch .../ssl_ex
> From: Sander Striker [mailto:[EMAIL PROTECTED]]
> Sent: 17 September 2002 20:59
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: 17 September 2002 20:44
>
> >>> I would also recommend a new tarball with the timestamp tweaked. Something
> >>> like so:
> >>>
> >>> $ tar xzf http
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 17 September 2002 20:44
>>> I would also recommend a new tarball with the timestamp tweaked. Something
>>> like so:
>>>
>>> $ tar xzf httpd-tar.gz
>>> $ touch .../ssl_expr_parse.c
>>> $ tar czf httpd-tar.gz httpd-...
>>>
>>> T
> > I would also recommend a new tarball with the timestamp tweaked. Something
> > like so:
> >
> > $ tar xzf httpd-tar.gz
> > $ touch .../ssl_expr_parse.c
> > $ tar czf httpd-tar.gz httpd-...
> >
> > That's gonna affect the tarball's MD5 signature tho.
>
> And the PGP signatures. Do
On Tue, 17 Sep 2002, Greg Stein wrote:
> On Tue, Sep 17, 2002 at 10:26:02AM -0700, Aaron Bannert wrote:
> > On Tue, Sep 17, 2002 at 01:00:44PM -0400, Ryan Bloom wrote:
> > > > Does that make any sense? I'm certain you will have users misconfigure
> > > > the 'backstop' modules (_default flavors)
> From: Greg Stein [mailto:[EMAIL PROTECTED]]
> Sent: 17 September 2002 20:31
> On Tue, Sep 17, 2002 at 12:56:21PM +0200, Sander Striker wrote:
> > > From: Mads Toftum [mailto:[EMAIL PROTECTED]]
> > > Sent: 17 September 2002 12:38
> >
> > > On Tue, Sep 17, 2002 at 03:41:15AM +0200, Sander Strike
On Tue, Sep 17, 2002 at 12:56:21PM +0200, Sander Striker wrote:
> > From: Mads Toftum [mailto:[EMAIL PROTECTED]]
> > Sent: 17 September 2002 12:38
>
> > On Tue, Sep 17, 2002 at 03:41:15AM +0200, Sander Striker wrote:
> > > Hi,
> > >
> > > I've tagged and rolled 2.0.41. Please test the tarballs
>-- Original Message --
>Date: Tue, 17 Sep 2002 11:19:53 -0700
>From: Greg Stein <[EMAIL PROTECTED]>
>Subject: Re: auth stuff still broken
>
>
>But since our running of auth hooks comes from server/, then this stuff
>could prolly go there as well. IMO, it sucks that our "core" server knows
>about
>-- Original Message --
>Date: Tue, 17 Sep 2002 10:26:02 -0700
>From: Aaron Bannert <[EMAIL PROTECTED]>
>Subject: Re: auth stuff still broken
>
>
>+1 for the core, or at least a module that's always statically compiled
>(which is easy to do with the .m4 macros we have).
Yup - I suppose if we do
On Tue, Sep 17, 2002 at 10:26:02AM -0700, Aaron Bannert wrote:
> On Tue, Sep 17, 2002 at 01:00:44PM -0400, Ryan Bloom wrote:
> > > Does that make any sense? I'm certain you will have users misconfigure
> > > the 'backstop' modules (_default flavors) resulting in insecure servers.
> > > If the 'ba
On Tue, Sep 17, 2002 at 01:00:44PM -0400, Ryan Bloom wrote:
> > Does that make any sense? I'm certain you will have users misconfigure
> > the 'backstop' modules (_default flavors) resulting in insecure servers.
> > If the 'backstop' _default auth handlers are always loaded as part of the
> > cor
At 12:04 PM 9/17/2002, Ian Holsman wrote:
>On Tue, 17 Sep 2002 10:00:44 -0700, rbb wrote:
> > On Tue, 17 Sep 2002, William A. Rowe, Jr. wrote:
> >> Mod_auth would further include all of the hooks, and be the common
> >> module that all other mod_auth_foo, authn and authz modules require.
> >>
> >>
On Tue, Sep 17, 2002 at 11:50:56AM -0500, William A. Rowe, Jr. wrote:
> I was thinking about this. What about -eliminating- the mod_authn_default
> and mod_authz_default, merging them into mod_auth, and moving the
> directives from mod_auth_basic and mod_auth_digest into the common
> mod_auth.
R
On Tue, 17 Sep 2002 10:00:44 -0700, rbb wrote:
> On Tue, 17 Sep 2002, William A. Rowe, Jr. wrote:
>
>> I was thinking about this. What about -eliminating- the
>> mod_authn_default and mod_authz_default, merging them into mod_auth, and
>> moving the directives from mod_auth_basic and mod_auth_di
On Tue, 17 Sep 2002, William A. Rowe, Jr. wrote:
> I was thinking about this. What about -eliminating- the mod_authn_default
> and mod_authz_default, merging them into mod_auth, and moving the
> directives from mod_auth_basic and mod_auth_digest into the common
> mod_auth.
>
> Mod_auth would fu
I was thinking about this. What about -eliminating- the mod_authn_default
and mod_authz_default, merging them into mod_auth, and moving the
directives from mod_auth_basic and mod_auth_digest into the common
mod_auth.
Mod_auth would further include all of the hooks, and be the common
module that
a fresh build/install of .42-dev:
Cannot load
/.../modules/mod_authn_file.so into server:
/.../modules/mod_authn_file.so:
undefined symbol: authn_register_provider
stock httpd.conf is installed (by 'make install') with modules in this
order:
LoadModule authn_file_module modules/mod_authn_file
Ian Holsman wrote:
>
> Hi Greg,
>
> we are about to start into the wild wild world of linux, and I was
> wondering if you have any hints on what patches you would go with for a
> custom kernel to get maximum performance.. stuff like ingo's O(1)
> scheduler and the like..
I'm glad you asked, sin
On Tue, Sep 17, 2002 at 12:50:59AM -0700, Justin Erenkrantz wrote:
> I vote 'delete' as these were never formally released, hence
> no need to keep them for posterity. -- justin
I don't care if we delete them, since I don't at the moment see a
compelling reason to keep them around unless we deci
On 17 Sep 2002, Brian Pane wrote:
> On Mon, 2002-09-16 at 23:32, Justin Erenkrantz wrote:
> > On Mon, Sep 16, 2002 at 09:46:47AM -0700, Brian Pane wrote:
> > > I disagree entirely. There's no need to let the API keep changing
> > > continuously, especially not for the sake of "correctness." All
William A. Rowe, Jr. wrote:
> I agree it would be nice to repost an OpenSSL/mod_ssl advisory on our
> pages (mod_ssl is a sister project, after all.)
>
> But understand that the ASF took ownership of mod_ssl for Apache 2.0,
> not 1.3, and we not married to any particular SSL library (although ma
On Mon, 2002-09-16 at 23:32, Justin Erenkrantz wrote:
> On Mon, Sep 16, 2002 at 09:46:47AM -0700, Brian Pane wrote:
> > I disagree entirely. There's no need to let the API keep changing
> > continuously, especially not for the sake of "correctness." All of
> > our competitors provide API stabili
Bojan Smojver wrote:
> I guess the HTML file would get generated automatically, but I'm
> attaching it anyway.
Thanks. Both the FAQ and glossary entries are committed.
Joshua.
Thank you, I will experiment with mutex protection and see if it makes
things more stable.
I am not very familiar with the sourcecode, but it does look very strange to
me. Even the (unused?) status function has mutex protection -:)
amund
-Original Message-
From: Jeff Trawick [mailto
Amund Elstad <[EMAIL PROTECTED]> writes:
> Hi,
>
> Can someone please explain why ssl_scache_dbm_retrieve() in
> modules/ssl/ssl_scache_dbm.c
> is not protected by the the SSLMutex ?
>
> The function uses the same pool (module config) as the store/remove/expire
> operations,
> so shouldn't i
> From: Mads Toftum [mailto:[EMAIL PROTECTED]]
> Sent: 17 September 2002 12:38
> On Tue, Sep 17, 2002 at 03:41:15AM +0200, Sander Striker wrote:
> > Hi,
> >
> > I've tagged and rolled 2.0.41. Please test the tarballs found
> > at http://httpd.apache.org/dev/dist/ and cast thy votes.
> >
> One
On Tue, Sep 17, 2002 at 03:41:15AM +0200, Sander Striker wrote:
> Hi,
>
> I've tagged and rolled 2.0.41. Please test the tarballs found
> at http://httpd.apache.org/dev/dist/ and cast thy votes.
>
One very small issue when building (tested on solaris 8 sparc) with
ssl_expr_parse.y in modules/ss
On Tue, 2002-09-17 at 16:20, Justin Erenkrantz wrote:
> Is there a reason that everything can't be done on the conn_rec?
> What's the reason for having the request-based input filter again?
> (Please refresh my old and decrepit memory!) Can't we do everything
> in the connection filter? Isn't t
Hi,
Can someone please explain why ssl_scache_dbm_retrieve() in
modules/ssl/ssl_scache_dbm.c
is not protected by the the SSLMutex ?
The function uses the same pool (module config) as the store/remove/expire
operations,
so shouldn't it also be protected to avoid race conditions ?
Our ssl-ena
On Tue, Sep 17, 2002 at 09:59:58AM +0200, Sander Striker wrote:
> Hi,
>
> When uploading the 2.0.41 tarballs I encountered an 'old'
> folder in /www/httpd.apache.org/dev/dist. Upon inspection
> it contains two unreleased alpha tarballs. Do we really
> want to keep history of our unreleased tarb
Hi,
When uploading the 2.0.41 tarballs I encountered an 'old'
folder in /www/httpd.apache.org/dev/dist. Upon inspection
it contains two unreleased alpha tarballs. Do we really
want to keep history of our unreleased tarballs? Or can
we just delete this directory?
Sander
49 matches
Mail list logo
