APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2002/08/19 15:46:24 $]
Release:
2.0.41 : in development.
2.0.40 : released August 9, 2002 as GA.
2.0.39 : released June 17, 2002 as GA.
2.0.38 : rolled June 16, 2002. not rele
APACHE 1.3 STATUS: -*-text-*-
Last modified at [$Date: 2002/06/27 20:57:21 $]
Release:
1.3.27-dev: In development
1.3.26: Tagged June 18, 2002.
1.3.25: Tagged June 17, 2002. Not released.
1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 20
mod_rewrite.c
D:\Apache\httpd-2.0\modules\mappers\mod_rewrite.c(2790) : warning C4013:
'lookup_map_dbmfile' undefined; assuming extern returning int
D:\Apache\httpd-2.0\modules\mappers\mod_rewrite.c(2790) : warning C4047:
'=' : 'char *' differs in levels of indirection from 'int '
D:\Apache\http
[EMAIL PROTECTED] wrote:
>r->bytes_sent needs to be just content data to be backwards
>compatible. As for two fields to get the information, I am not sure why
>we need two fields.
>
We need two fields in order to compute r->bytes_sent in the first place.
If we compute r->bytes_sent based on c->
On Wed, 21 Aug 2002, Brian Pane wrote:
> Bojan Smojver wrote:
>
> >On Thu, 2002-08-22 at 09:03, [EMAIL PROTECTED] wrote:
> >
> >
> IMO, the best solution is to move the bytes_sent information to the
> conn_rec, and have the protocol module reset it whenever it wants to. For
> back
On Wed, Aug 21, 2002 at 04:15:55PM -0700, Brian Pane wrote:
> Bojan Smojver wrote:
..
> >So, bytes_sent will continue to be the amount of body sent out only, no
> >headers? If that's the case, then the only option (if we want to know
> >total counts) is to introduce bytes_pushed and bytes_pulled (
On Wed, Aug 21, 2002 at 03:19:07PM -0700, Greg Stein wrote:
> That would be best. The admin could then select GDBM moving forwards (the
> best DBM of the bunch) [and assuming the admin can convert any pre-existing
> ndbm files to gdbm thru some tool]
Eh, no. GDBM isn't thread-safe. -- justin
On Thu, 2002-08-22 at 09:15, Brian Pane wrote:
> That sounds reasonable, although we might end up with some data
> from which it's possible to compute bytes_pushed, rather than an
> actual bytes_pushed field. With the c->bytes_sent idea that Ryan
> and I were just discussing, we'd probably have
Bojan Smojver wrote:
>On Thu, 2002-08-22 at 09:03, [EMAIL PROTECTED] wrote:
>
>
IMO, the best solution is to move the bytes_sent information to the
conn_rec, and have the protocol module reset it whenever it wants to. For
backwards compat, it would be REALLY cool, if the r->bytes_s
On Thu, 2002-08-22 at 09:03, [EMAIL PROTECTED] wrote:
>
> > > IMO, the best solution is to move the bytes_sent information to the
> > > conn_rec, and have the protocol module reset it whenever it wants to. For
> > > backwards compat, it would be REALLY cool, if the r->bytes_sent could be
> > > l
> >Adding the request_rec to the bucket is a bad idea, because currently
> >buckets have no concept of Apache internals, and I would prefer that they
> >stay that way.
> >
>
> The trick is to not add the request_rec to the bucket: just add a
> void* "client_data" field to the bucket, so that apr
> > IMO, the best solution is to move the bytes_sent information to the
> > conn_rec, and have the protocol module reset it whenever it wants to. For
> > backwards compat, it would be REALLY cool, if the r->bytes_sent could be
> > linked to c->bytes_sent, but it can't, so oh well.
>
> Why don't
[EMAIL PROTECTED] wrote:
>The cleanest solution, is to move the bytes_sent to the conn_rec, but then
>it should really be per-connection, not per-request, and we want it to be
>per-request.
>
>The other solution is to have the core figure out the correct amount of
>data in the core_output_filter
On Thu, 2002-08-22 at 08:40, [EMAIL PROTECTED] wrote:
> Sorry, I assumed that value was in the conn_rec, becasue we are talking
> about the core_output_filter. Of course, it isn't, which makes this a lot
> harder to do.
>
> The cleanest solution, is to move the bytes_sent to the conn_rec, but
Greg Stein <[EMAIL PROTECTED]> writes:
> On Wed, Aug 21, 2002 at 12:21:17PM -0400, Jeff Trawick wrote:
> > questions for *dbm gurus... is a switch from 1.3's ndbm usage to
> > apr-util's built-in sdbm going to hurt anybody (file compatibility)?
> >
> > is it going to be necessary to let the adm
> >>c->bytes_sent? Did you mean r->bytes_sent? The conn_rec doesn't
> >>have a byte count.
> >>
> >>
> >
> >Yeah, sorry.
> >
> >
>
> Okay, now I'm less confused. :-) But we still have the problem of
> updating r->bytes_sent from the core output filter, given that we
> don't have access
Ian Holsman <[EMAIL PROTECTED]> writes:
> > Cool... I think I should change my mod_rewrite patch to do something
> > like the following:
> > #if APU_HAVE_NDBM
> > #define DBM_MAP_TYPE "NDBM"
> > #else
> > #define DBM_MAP_TYPE "SDBM"
> > #endif
>
> hmm.. you should probably change this to
> #i
On Wed, Aug 21, 2002 at 12:21:17PM -0400, Jeff Trawick wrote:
> questions for *dbm gurus... is a switch from 1.3's ndbm usage to
> apr-util's built-in sdbm going to hurt anybody (file compatibility)?
>
> is it going to be necessary to let the admin choose the file format
> from among the formats
Jeff Trawick wrote:
> Ian Holsman <[EMAIL PROTECTED]> writes:
>
>
>>Jeff Trawick wrote:
>>
>>>questions for *dbm gurus... is a switch from 1.3's ndbm usage to
>>>apr-util's built-in sdbm going to hurt anybody (file compatibility)?
>>>
>>
>>It will.
>>but the easiest way to handle this is to sup
On Thu, 2002-08-22 at 06:44, Bojan Smojver wrote:
> > I think you are right, actually. The CVS version of http_protocol.c is
> > different then the one from Apache 2.0.40. It contains a function
> > update_r_in_filters(), which (I think) does that. Or maybe it's just
> > wishful thinking on my b
On Wed, 2002-08-21 at 21:49, Bojan Smojver wrote:
> On Wed, 2002-08-21 at 17:37, Justin Erenkrantz wrote:
> > On Wed, Aug 21, 2002 at 12:27:29AM -0700, Brian Pane wrote:
> > > The remaining problem is: how can we identify the request_rec from
> > > within core_output_filter()? Within that filter,
[EMAIL PROTECTED] wrote:
>On Wed, 21 Aug 2002, Brian Pane wrote:
>
>
>
>>[EMAIL PROTECTED] wrote:
>>
>>
>>
>>>To solve the original problem, just look for ap_check_pipeline_flush, and
>>>around that function (or in the core's log_transaction phase), just reset
>>>c->bytes_sent to 0. If you
On Wed, 21 Aug 2002, Brian Pane wrote:
> [EMAIL PROTECTED] wrote:
>
> >To solve the original problem, just look for ap_check_pipeline_flush, and
> >around that function (or in the core's log_transaction phase), just reset
> >c->bytes_sent to 0. If you do it in the core's log_transaction phase,
[EMAIL PROTECTED] wrote:
>To solve the original problem, just look for ap_check_pipeline_flush, and
>around that function (or in the core's log_transaction phase), just reset
>c->bytes_sent to 0. If you do it in the core's log_transaction phase,
>just make sure that the function is registered AP
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> > > I wouldn't want to see it added to httpd-2.0 or apr-util unless the
> > > non-API helper macros are removed from the public header file.
> >
> >Good idea.
>
> or, they are considered worthwhile enough for httpd itself [or a good
> minority
Ian Holsman <[EMAIL PROTECTED]> writes:
> Jeff Trawick wrote:
> > questions for *dbm gurus... is a switch from 1.3's ndbm usage to
> > apr-util's built-in sdbm going to hurt anybody (file compatibility)?
> >
> It will.
> but the easiest way to handle this is to support ndbm in apr-util.
> I've g
On Wed, Aug 21, 2002 at 08:06:41AM -0700, Ian Holsman wrote:
> Sébastien Bonnegent wrote:
> > Hi,
> >
> > My purpose is sharing a data structure.
> > For example with an array:
> > - httpd creation, my_array is empty
> > - there are 8 servers launched
> > - server1 add an entry named (X)
> > - se
Joe Schaefer wrote:
> "William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
>
> [...]
>
>
>>Here's an odd idea Stas and I kicked around... why not port apreq2.0
>>into a filter? This is the idea;
>>
>>Folks writing a body-consuming -filter- could call the prepare fn to
>>inject the apreq filter i
By the way, this was submitted by me and reviewed by Jeff Trawick.
Paul J. Reder wrote:
> I am both embedding and attaching the APR fix since my e-mail editor
> seems to munge patches...
>
> This is to fix the command arg parsing for mod_ext_filter to provide
> the normal quote and escaped quot
I am both embedding and attaching the APR fix since my e-mail editor
seems to munge patches...
This is to fix the command arg parsing for mod_ext_filter to provide
the normal quote and escaped quote processing.
The files impacted are:
httpd-2.0/CHAGES
httpd-2.0/modules/experimental/mod_ext_filte
Jeff Trawick wrote:
> questions for *dbm gurus... is a switch from 1.3's ndbm usage to
> apr-util's built-in sdbm going to hurt anybody (file compatibility)?
>
It will.
but the easiest way to handle this is to support ndbm in apr-util.
I've got a patch from someone to do this.. I've just been la
questions for *dbm gurus... is a switch from 1.3's ndbm usage to
apr-util's built-in sdbm going to hurt anybody (file compatibility)?
is it going to be necessary to let the admin choose the file format
from among the formats supported by apr-util?
how would one easily create rewrite mappings fo
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
[...]
> Here's an odd idea Stas and I kicked around... why not port apreq2.0
> into a filter? This is the idea;
>
> Folks writing a body-consuming -filter- could call the prepare fn to
> inject the apreq filter into the input chain. If more t
* Justin Erenkrantz ([EMAIL PROTECTED]) wrote :
> On Sat, Aug 17, 2002 at 08:14:30PM +0100, Thom May wrote:
> > As the title says. I've been running into this problem on numerous debian
> > installs.
>
> I believe this patch may not work on Win32 and Netware. Hint:
> look at where DEFAULT_REL_RU
Sébastien Bonnegent wrote:
> Hi,
>
> My purpose is sharing a data structure.
> For example with an array:
> - httpd creation, my_array is empty
> - there are 8 servers launched
> - server1 add an entry named (X)
> - server5 add an entry
> - server3 read an entry
> - server7 remove the (X) entry
>
On 21 Aug 2002, Jeff Trawick wrote:
> Joe Schaefer <[EMAIL PROTECTED]> writes:
>
> > The apreq developers would like to see apreq-2 [*]
> > make its way into the apache 2 distribution. Here's why:
>
> Did you consider adding it to apr-util? (probably a dumb idea, but I'm
> interested in what
On Wed, 21 Aug 2002, Justin Erenkrantz wrote:
> On Wed, Aug 21, 2002 at 12:27:29AM -0700, Brian Pane wrote:
> > The remaining problem is: how can we identify the request_rec from
> > within core_output_filter()? Within that filter, f->r is NULL. I
> > have some ideas for solving this by putting
Jamni wrote:
> Hi all
>
> I am just thinking whether i can alter the module mod_log_config to log
> all the accesses/errors into another user-defined file, in addition to
> the original access/error log files. Can anyone tell me how i could do
> this ?? Or do i need to write a new module for
Graham Leggett wrote:
> Hi all,
>
> In the v2.0 proxy, the following code exists:
>
> /* In order for ap_set_keepalive to work properly, we can NOT
> * have any length information stored in the output headers.
> Surely the correct fix is to make sure that ap_set_keepali
At 06:53 AM 8/21/2002, Joe Schaefer wrote:
>Jeff Trawick <[EMAIL PROTECTED]> writes:
>
> > Joe Schaefer <[EMAIL PROTECTED]> writes:
> >
> > > The apreq developers would like to see apreq-2 [*]
> > > make its way into the apache 2 distribution. Here's why:
> >
> > Did you consider adding it to apr
Hi,
My purpose is sharing a data structure.
For example with an array:
- httpd creation, my_array is empty
- there are 8 servers launched
- server1 add an entry named (X)
- server5 add an entry
- server3 read an entry
- server7 remove the (X) entry
After this, my_array contains one line which is
On Wed, 21 Aug 2002, Thom May wrote:
> Hi Guys,
> this is a newly filed bug from the debian www team; it holds for apache2
> and
> is a real problem for us.
As this person seems to somewhat realize, Apache's behavior in this case
is following the requirements in the standard. It is the browser
Hi,
I am running apache 2.0.40 on
RedHat 7.2 x86
I have done a module reading
POST (body) data in the input filter.
The problem is when I read
the data on the bucket, I am not able to let the data available for the other
module.
I have tried to copy the
bucket before read it, o
Hi Guys,
this is a newly filed bug from the debian www team; it holds for apache2 and
is a real problem for us.
-Thom
--
Thom May -> [EMAIL PROTECTED]
stibbons: Good morning Mr Moo-lay
Moo-lay?
stibbons: It's French for mullet
--- Begin Message ---
Package: apache
Severity: wishlist
Version
Jeff Trawick <[EMAIL PROTECTED]> writes:
> Joe Schaefer <[EMAIL PROTECTED]> writes:
>
> > The apreq developers would like to see apreq-2 [*]
> > make its way into the apache 2 distribution. Here's why:
>
> Did you consider adding it to apr-util? (probably a dumb idea, but I'm
> interested in
On Wed, 2002-08-21 at 17:37, Justin Erenkrantz wrote:
> On Wed, Aug 21, 2002 at 12:27:29AM -0700, Brian Pane wrote:
> > The remaining problem is: how can we identify the request_rec from
> > within core_output_filter()? Within that filter, f->r is NULL. I
> > have some ideas for solving this by
* Jeff Trawick ([EMAIL PROTECTED]) wrote :
> Joe Schaefer <[EMAIL PROTECTED]> writes:
>
> > The apreq developers would like to see apreq-2 [*]
> > make its way into the apache 2 distribution. Here's why:
>
> Did you consider adding it to apr-util? (probably a dumb idea, but I'm
> interested in
Joe Schaefer <[EMAIL PROTECTED]> writes:
> The apreq developers would like to see apreq-2 [*]
> make its way into the apache 2 distribution. Here's why:
Did you consider adding it to apr-util? (probably a dumb idea, but I'm
interested in what other people think)
I wouldn't want to see it adde
On Wed, 2002-08-21 at 18:13, Brian Pane wrote:
> But filters can be added after the request is created (e.g.,
> adding the mod_include filter based on file extension)
>
> I think it would be sufficient to "fixup" just the
> core_output_filter, though.
Would that leave us with no information abo
On Wed, 2002-08-21 at 18:07, Brian Pane wrote:
> Yes, it's NULL in core_input_filter() too.
:-(
Bojan
On Tue, Aug 20, 2002 at 02:54:52AM -0400, Cliff Woolley wrote:
> On Fri, 16 Aug 2002, Hector A. Paterno wrote:
>
> > Hi, I have found a discrepancy between mod_auth and ServerTokens Prod.
> > HEAD / HTTP/1.0\r\n\r\n
> > Server: Apache
> > 401 Authorization Required
> > [bleh bleh info]
> > Ap
Sorry for the cross-post, but I don't know which side is
causing this bug, Apache or PHP.
OS: Solaris 8
Apache: 1.3.26
PHP: 4.2.2 (DSO)
By default, PHP sets "max_post_size" to 8Mb. If the post
data exceeds that, it seems PHP discards all of it (no post
data gets to the script). In my situation "
On Wed, Aug 07, 2002 at 08:41:41PM -0400, Rob Saccoccio wrote:
> At any rate, I've got alternatives if you think it should remain the way it
> is (say to accommodate the use of the SuexecUserGroup at a finer config
> granularity).
I would very much like to do (in Apache 1.3 syntax):
ServerNam
Hello...
True, but I would like to know what the 'official' name should be.
>> > Oh, I know, but I believe it is "Apache HTTP Server Project" and its
>> > abbreviation is httpd.
>>
>> This is correct, FWIW.
AB> Wait, now we have two people stating different "official" names. Either
AB> it has
The apreq developers would like to see apreq-2 [*]
make its way into the apache 2 distribution. Here's why:
1) Having a built-in library for parsing cookies, url-encoded
query strings, and POST data would be useful for other bundled
core modules, e.g. mod_usertrack, mod_isapi. It wou
The apreq developers would like to see apreq-2 [*]
make its way into the apache 2 distribution. Here's why:
1) Having a built-in library for parsing cookies, url-encoded
query strings, and POST data would be useful for other bundled
core modules, e.g. mod_usertrack, mod_isapi. It wou
Justin Erenkrantz wrote:
>On Wed, Aug 21, 2002 at 12:27:29AM -0700, Brian Pane wrote:
>
>
>>The remaining problem is: how can we identify the request_rec from
>>within core_output_filter()? Within that filter, f->r is NULL. I
>>have some ideas for solving this by putting some metadata in the
Bojan Smojver wrote:
>Quoting Brian Pane <[EMAIL PROTECTED]>:
>
>
>
>>I think it's easy to solve the keepalive problem: core_output_filter()
>>just needs to set r->bytes_sent as soon as it sees the EOS, rather than
>>waiting until it writes the data. In the keepalive case, this means
>>updatin
Hi all,
In the v2.0 proxy, the following code exists:
/* In order for ap_set_keepalive to work properly, we can NOT
* have any length information stored in the output headers.
*/
apr_table_unset(r->headers_out,"Transfer-Encoding");
Quoting Brian Pane <[EMAIL PROTECTED]>:
> I think it's easy to solve the keepalive problem: core_output_filter()
> just needs to set r->bytes_sent as soon as it sees the EOS, rather than
> waiting until it writes the data. In the keepalive case, this means
> updating r->bytes_sent before the cod
On Wed, Aug 21, 2002 at 12:27:29AM -0700, Brian Pane wrote:
> The remaining problem is: how can we identify the request_rec from
> within core_output_filter()? Within that filter, f->r is NULL. I
> have some ideas for solving this by putting some metadata in the
> brigade to associate each EOS w
Chris Taylor wrote:
> I have setup a proxy server on Apache, but if the upstream webserver is
> off at the time, it's pages return 502/Bad Gateway, presumably via
> mod_proxy.
>
> However, under Apache 2 (2.0.39 on win32 at least), the errors look like
> this (taken straight from the browser
Justin Erenkrantz wrote:
>>Everything here (core_output_filter) revolves around apr_brigade_write
>>and local variable n, which looks like the number of bytes that are
>>about to go down the pipe:
>>
>>- to establish the total, we do:
>>
>> f->r->bytes_sent += n;
>>
>> after each write
>>
>>All
Hi all
I am just thinking whether i can alter the module mod_log_config to log all
the accesses/errors into another user-defined file, in addition to the original
access/error log files. Can anyone tell me how i could do this ?? Or do i need
to write a new module for this ??
Thanks
Jamn
64 matches
Mail list logo
