From: William A. Rowe, Jr.
One (extreme) hassle is leaving the
httpd code legible to httpd'ers
and leaving .NET code legible to .NET'ers.
I had chosen the conventions of using
'traditional' variable names for httpd datum,
and 'wordy' variable names for the internals of
Apache.Web.
In
Feel free to offer a patch to build under nant, msbuild or any
method that proves viable!
The problem, is that the delayimp.lib is not distributed with
the .NET Visual C++ compiler - this makes it impossible to
build our c++ code outside of the full Visual Studio.
I'm actually much more
From: William A. Rowe, Jr.
let me get ahold of my life first
I see you doing so much, what life?
More later
Jeff
When we attempted to run make, we ran into the following
build/rules.mk:57: /build/config_vars.mk: No such file or directory
What option if any controls the location of config_vars.mk?
Thanks.
Graham Leggett wrote:
Hi all,
I've been keen to do some digging for reasons why someone might need to
install httpd v1.3 instead of v2.0 or later.
Support for mod_backhand seems to be a significant reason (and getting
backhand ported to v2.0 would be a win): Apart from backhand, are there
in
On Mon, 22 Nov 2004, Mathias Herberts wrote:
The main reason why we are not migrating to 2 is related to bug 17877 I
filed for Apache 1.3 last year.
Erm, you file a bug report for Apache 1 and treat it as a reason not to
upgrade to apache 2? Should I Cc: this to Scott Adams?
If you'd filed a
Nick Kew wrote:
On Mon, 22 Nov 2004, Mathias Herberts wrote:
The main reason why we are not migrating to 2 is related to bug 17877 I
filed for Apache 1.3 last year.
Erm, you file a bug report for Apache 1 and treat it as a reason not to
upgrade to apache 2? Should I Cc: this to Scott Adams?
On Mon, 22 Nov 2004, Mathias Herberts wrote:
Nick Kew wrote:
On Mon, 22 Nov 2004, Mathias Herberts wrote:
The main reason why we are not migrating to 2 is related to bug 17877 I
filed for Apache 1.3 last year.
Erm, you file a bug report for Apache 1 and treat it as a reason not to
There's another mod_deflate vs 304 response problem which is being
triggered by ViewCVS on svn.apache.org: when a CGI script gives a
Status: 304 response the brigade contains a CGI bucket then the EOS,
so fails the if this brigade begins with EOS do nothing test added for
the proxied-304 case.
I
On Sat, 20 Nov 2004 12:11:34 -0500, Jeff Trawick [EMAIL PROTECTED] wrote:
The ScriptSock directive must be used when there are two instances of
the server with same ServerRoot. If it is omitted, symptoms may
include
. wrong credentials for CGIs
. CGIs stop working for one server when other
Paul Querna wrote:
I have Paul's version of the Event MPM patch up and running. The only
glitch I saw bringing it up was a warning for two unused variables in
http_core.c (patchlet below). Then I tried stressing it with
SPECweb99 and saw some errors after several minutes:
[error] (24)Too
William A. Rowe, Jr. wrote:
At 11:03 PM 11/19/2004, Justin Erenkrantz wrote:
--On Friday, November 19, 2004 8:01 PM -0600 William A. Rowe, Jr. [EMAIL
PROTECTED] wrote:
I'll offer compelling argument. Allen offered patches, which
Roy vetoed, to fix object sizes on 32/64/64 ILP bit platforms,
and
William A. Rowe, Jr. wrote:
At 08:23 AM 11/20/2004, Jim Jagielski wrote:
On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote:
So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- justin
+1. Of
Paul Querna wrote:
So, we are nearing a new stable branch. For the first time in a long
time we will have a no-longer-developed-but-stable-branch in wide use.
(2.0.x)
I would like to have a semi-official policy on how long we will provide
security backports for 2.0 releases.
I suggest a
At 10:08 AM 11/22/2004, Bill Stoddard wrote:
William A. Rowe, Jr. wrote:
At 08:23 AM 11/20/2004, Jim Jagielski wrote:
On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote:
So, my opinion is that we let Allen branch apr off now and let him go at it
at a measured pace, but we shouldn't intend
Nick Kew wrote:
Well, mod_proxy in Apache 1.x doesn't claim to be HTTP/1.1, so there's no
reason it should be expected to support chunked encoding. And since
Apache 1.x is a maintenance-only product not in active development,
that's not too likely to change - ever.
The mod_proxy in v1.3 does
Bill Stoddard wrote:
William A. Rowe, Jr. wrote:
At 08:23 AM 11/20/2004, Jim Jagielski wrote:
On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote:
So, my opinion is that we let Allen branch apr off now and let him go at
it at a measured pace, but we shouldn't intend to hold
On Monday 22 November 2004 09:11, Bill Stoddard wrote:
Why drive artificial constraints on any of our release processes? If a
sizeable number of people (ie, a community) are interested in maintaining
2.0 for the next 20 years, then why prevent it 'by decree'?
Id certainly have to agree with
On Mon, 22 Nov 2004, Joe Orton wrote:
There's another mod_deflate vs 304 response problem which is being
triggered by ViewCVS on svn.apache.org: when a CGI script gives a
Status: 304 response the brigade contains a CGI bucket then the EOS,
so fails the if this brigade begins with EOS do
Cliff Woolley wrote:
Okay, but why the next three lines? Why would Content-Encoding: gzip
*ever* be set on a 304?
In theory the 304 might be in response to a freshness check on the
particular variant that was compressed. (Assuming I am not mixing up my
content and transfer encodings).
Regards,
On Mon, Nov 22, 2004 at 11:26:18AM -0500, Cliff Woolley wrote:
On Mon, 22 Nov 2004, Joe Orton wrote:
There's another mod_deflate vs 304 response problem which is being
triggered by ViewCVS on svn.apache.org: when a CGI script gives a
Status: 304 response the brigade contains a CGI bucket
At 11:08 AM 11/22/2004, Cliff Woolley wrote:
On Mon, 22 Nov 2004, William A. Rowe, Jr. wrote:
Yes - I understand that this means 1.x will never be used by
httpd. Version numbers are cheap. The APR project should
become used to this, if they are active, and httpd moves at
it's normal pace,
On Mon, 22 Nov 2004, Joe Orton wrote:
Okay, but why the next three lines? Why would Content-Encoding: gzip
*ever* be set on a 304?
I was wondering that too. The answer to the latter is that it *won't*
be sent for a 304 because the http_header filter knows better than that.
Well, okay.
On Mon, 22 Nov 2004, William A. Rowe, Jr. wrote:
Yes - I understand that this means 1.x will never be used by
httpd. Version numbers are cheap. The APR project should
become used to this, if they are active, and httpd moves at
it's normal pace, it would be easy to go through APR 2.x, 3.x,
* Jeff Trawick [EMAIL PROTECTED] wrote:
code to check for the misconfiguration is small and is expected to be
fool-proof (independent of what the user does); also, no way the
change can result in stale unix sockets left around, unlike sticking
the pid in the filename
see patch in
Hi all,
I have attached a small filter module that strips leading whitespace
from text files. This would typically be used to remove the indenting
whitespace found inside HTML files, resulting in a significant reduction
in network traffic for some sites.
I didn't bother to include trailing
--On Monday, November 22, 2004 11:27 AM -0500 Jim Jagielski [EMAIL PROTECTED]
wrote:
I agree... Otherwise, we won't see many people move to
2.2 since 3rd party modules won't be available for it,
since module developers will know that within a short
amount of time, they'll need to redo their
Graham Leggett wrote:
Hi all,
I have attached a small filter module that strips leading whitespace
from text files. This would typically be used to remove the indenting
whitespace found inside HTML files, resulting in a significant reduction
in network traffic for some sites.
I didn't bother
At 12:17 PM 11/22/2004, Justin Erenkrantz wrote:
I expect that as it stands right now most 2.0 modules will compile for 2.2
with very minor (if any) changes. If we 'fix' 64-bit issues now, then that
means that their modules are going to undergo massive changes.
This I will attest to;
On Mon, 22 Nov 2004 [EMAIL PROTECTED] wrote:
Author: nd
Date: Mon Nov 22 05:43:39 2004
New Revision: 106181
Modified:
httpd/httpd/branches/2.0.x/docs/manual/mod/core.html.de
httpd/httpd/branches/2.0.x/docs/manual/mod/core.html.en
httpd/httpd/branches/2.0.x/docs/manual/mod/core.html.ja.euc-jp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Due to the huge variety and creativity displayed by those fine folks who
package the Apache Web Server up for distribution with the gzillion
operating systems which come with it, users tend to have problems with
the default configuration, which seem
--On Monday, November 22, 2004 1:08 PM -0600 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
That *will* affect the 2.2 uptake rate because our third parties will
take a lot of time to get their modules 64-bit clean (if they do at all).
WHO CARES?!? That's on them. They can release bug fixes
Bill Stoddard wrote:
+1 in concept but code not reviewed. mod_deflate would effectivly do the
same thing, right? What user base would are we targeting with this
module (looking for an answer a bit more specific than 'web clients that
don't support gzip decoding').
Bandwidth reduction for
At 10:26 AM 11/22/2004, Cliff Woolley wrote:
On Mon, 22 Nov 2004, Joe Orton wrote:
There's another mod_deflate vs 304 response problem which is being
triggered by ViewCVS on svn.apache.org: when a CGI script gives a
Status: 304 response the brigade contains a CGI bucket then the EOS,
so fails
Graham Leggett wrote:
Hi all,
I have attached a small filter module that strips leading whitespace
from text files. This would typically be used to remove the indenting
whitespace found inside HTML files, resulting in a significant reduction
in network traffic for some sites.
I didn't
On Mon, Nov 22, 2004 at 11:29:01AM -0500, Rich Bowen wrote:
To that end, I'd like to request Yet Another Mailing List, called
something like [EMAIL PROTECTED] or
[EMAIL PROTECTED], or some such.
The list would be public, although I'd be willing to moderate if needed.
Thoughts?
+1 - imo
Mads Toftum wrote:
+1 - imo there's more than enough mutilated httpd packages out there to
warrant such a list. Perhaps packagers@ would be better?
Would a packagers' list be restricted to httpd only, or would it include
other projects like APR?
I think it should.
Regards,
Graham
--
smime.p7s
On Mon, Nov 22, 2004 at 10:23:41PM +0200, Graham Leggett wrote:
Would a packagers' list be restricted to httpd only, or would it include
other projects like APR?
I think it should.
APR being a prerequisite for httpd certainly makes me think the same - but
I don't think we should spread
Mads Toftum wrote:
On Mon, Nov 22, 2004 at 10:23:41PM +0200, Graham Leggett wrote:
Would a packagers' list be restricted to httpd only, or would it include
other projects like APR?
I think it should.
APR being a prerequisite for httpd certainly makes me think the same - but
I don't think we
[EMAIL PROTECTED] wrote:
Log:
The Event MPM.
woo-hoo!
Thanks for driving this, Paul, and thanks to Justin and Sander for all the svn
work.
Status:
Should work as a drop in replacement for all non-ssl servers.
SSL Requests that use HTTP 1.1 Pipelining do not currently work.
cannot confirm or
Justin Erenkrantz wrote:
http://httpd.apache.org/dev/dist/
Grab the 2.1.1 tarballs while they're fresh. Please start testing
these releases - they should have the intent of becoming the beginning
of the 2.2.x series modulo all of the cleanup work we'll have to do
after we branch. For now,
On Mon, 22 Nov 2004, Graham Leggett wrote:
I have attached a small filter module that strips leading whitespace
from text files. This would typically be used to remove the indenting
whitespace found inside HTML files, resulting in a significant reduction
in network traffic for some sites. I
At 10:26 AM 11/22/2004, Cliff Woolley wrote:
On Mon, 22 Nov 2004, Joe Orton wrote:
There's another mod_deflate vs 304 response problem which is being
triggered by ViewCVS on svn.apache.org: when a CGI script gives a
"Status: 304" response the brigade contains a CGI bucket then the EOS,
so
--On Monday, November 22, 2004 5:30 PM -0500 [EMAIL PROTECTED] wrote:
Suggestion: Make sure someone can compress any response
they want via config but then make sure to NOT recommend
doing certain things and let them swim at their own risk.
No lifeguard on duty.
+1. -- justin
* [EMAIL PROTECTED] wrote:
Author: pquerna
Date: Mon Nov 22 14:55:35 2004
New Revision: 106229
Added:
httpd/site/branches/css-test/
- copied from r106228, httpd/site/trunk/
Log:
create a copy of the trunk to test out a CSS based website.
FWIW: I'd really like something based
André Malo wrote:
* [EMAIL PROTECTED] wrote:
Author: pquerna
Date: Mon Nov 22 14:55:35 2004
New Revision: 106229
Added:
httpd/site/branches/css-test/
- copied from r106228, httpd/site/trunk/
Log:
create a copy of the trunk to test out a CSS based website.
FWIW: I'd really like something
Currently the docs build tools are misplaced under infrastructure. I'd like to
have them moved from
/infrastructure/site-tools/trunk/httpd-docs-build/
to
/httpd/docs-build/trunk (or the like)
What do you think?
nd
--
Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3)
--On Tuesday, November 23, 2004 12:25 AM +0100 André Malo [EMAIL PROTECTED]
wrote:
Currently the docs build tools are misplaced under infrastructure. I'd like
to have them moved from
/infrastructure/site-tools/trunk/httpd-docs-build/
to
/httpd/docs-build/trunk (or the like)
What do you think?
+1.
* Justin Erenkrantz [EMAIL PROTECTED] wrote:
Currently the docs build tools are misplaced under infrastructure. I'd
like to have them moved from
/infrastructure/site-tools/trunk/httpd-docs-build/
to
/httpd/docs-build/trunk (or the like)
What do you think?
+1. If you don't
Hi All,
I'm investigating a difficult to diagnose problem and I came across the
following code in core_output_filter():
4152 nvec = 0;
4153 nbytes = 0;
4154 temp = APR_BRIGADE_FIRST(temp_brig);
4155
Cliff Woolley wrote:
On Mon, 22 Nov 2004, Graham Leggett wrote:
I have attached a small filter module that strips leading whitespace
from text files. This would typically be used to remove the indenting
whitespace found inside HTML files, resulting in a significant reduction
in network traffic
Currently the docs build tools are misplaced under infrastructure. I'd like to
have them moved from
/infrastructure/site-tools/trunk/httpd-docs-build/
to
/httpd/docs-build/trunk (or the like)
What do you think?
+1 from me.
---Hiroaki Kawai
Paul Querna [EMAIL PROTECTED] writes:
Author: pquerna
Date: Mon Nov 22 14:55:35 2004
New Revision: 106229
Added:
httpd/site/branches/css-test/
- copied from r106228, httpd/site/trunk/
Log:
create a copy of the trunk to test out a CSS based website.
FWIW: I'd really like something
André Malo [EMAIL PROTECTED] writes:
Currently the docs build tools are misplaced under infrastructure. I'd
like to have them moved from
/infrastructure/site-tools/trunk/httpd-docs-build/
to
/httpd/docs-build/trunk (or the like)
What do you think?
+1. If you don't have the
Geoffrey Young wrote:
Garrett Rooney wrote:
Justin Erenkrantz wrote:
--On Friday, September 17, 2004 1:07 PM -0400 Garrett Rooney
[EMAIL PROTECTED] wrote:
Could someone please take a look at bug 31228 in bugzilla?
It's just adding a new response code (226) which is defined in rfc3229.
I'm
On Mon, 22 Nov 2004, Ronald Park wrote:
I'm investigating a difficult to diagnose problem and I came across the
following code in core_output_filter():
Yuck. I HATE the core_output_filter. I probably know that code as well
as anybody, and yet every time I look at it, it makes my brain hurt
Quoting William A. Rowe, Jr. [EMAIL PROTECTED]:
Okay, but why the next three lines? Why would Content-Encoding: gzip
*ever* be set on a 304?
Because Content-* header fields in a 304 response describe
what the response entity would contain if it were a 200 response.
Therefore, the header field
57 matches
Mail list logo
