On 10/02/2007 01:04 AM, Alec Matusis wrote:
Have you checked without the MaxMemFree setting?
Why do you use MaxMemFree with such a small value at all?
I finally removed MaxMemFree altogether, and it crashed again. Nothing in
the apache error logs, but this is how /server-status looks like
On Tue, Oct 02, 2007 at 01:12:08AM +0100, Nick Kew wrote:
RFC2616 mandates that a proxy MUST return interim (1xx)
responses to an HTTP/1.1 client, except where the proxy
itself requested the interim response. I'd interpret
that slightly liberally, to mean we MUST return an interim
response
On Mon, Oct 01, 2007 at 02:22:11AM -0500, William Rowe wrote:
server/Makefile.in;
export_files:
tmp=export_files_unsorted.txt; \
rm -f $$tmp touch $$tmp; \
for dir in $(EXPORT_DIRS); do \
ls $$dir/*.h $$tmp; \
done; \
for dir in
On Mon, Oct 01, 2007 at 02:01:24AM +0100, Nick Kew wrote:
Coadvisor has several testcases involving a Content-Type line with
a lot of qualifier tokens. These tokens are quoted strings and
include backslashes. This is going to wrap when I cutpaste:
Content-Type: text/other;
On Oct 1, 2007, at 6:52 PM, William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
Give that some thought :)
One thing I'm pondering is a 2.3.0 alpha in the near future.
If only to give the we stay back at version n.x-1 crowd something
to chew on.
Not to mention that it would be good
On Oct 1, 2007, at 4:07 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
But, as I read it, the '*' in OPTIONS * does not really
mean a Location *... in other words, it's not a URI per se.
OPTIONS * asks for the capabilities of the server itself,
independent of URI... At least, that's
Comments?:
Index: modules/http/http_core.c
===
--- modules/http/http_core.c(revision 581205)
+++ modules/http/http_core.c(working copy)
@@ -234,6 +234,24 @@
return OK;
}
+static int http_send_options(request_rec *r)
+{
On 9/27/07, Eric Covener [EMAIL PROTECTED] wrote:
httpd's mod_ext_filter sets up a child process with a stdin of
APR_CHILD_BLOCK, but on windows the parent side of the stdin pipe
defaults to a non-blocking pipe with an infinite (-1) timeout. Such
a pipe in unix has its apr_file_pipe_timeout()
On Oct 2, 2007, at 10:10 AM, Rich Bowen wrote:
On Oct 2, 2007, at 08:24, Jim Jagielski wrote:
Well, we could do:
o Apache 1.3 and 2.0 deprecated
As part of the support community, I'd like to have this defined
pretty clearly.
I presume it can't mean no more bug fixes or security
On 10/2/07, Rich Bowen [EMAIL PROTECTED] wrote:
On Oct 2, 2007, at 08:24, Jim Jagielski wrote:
Well, we could do:
o Apache 1.3 and 2.0 deprecated
As part of the support community, I'd like to have this defined pretty
clearly.
I presume it can't mean no more bug fixes or security
On 01.10.2007, at 12:22, Erik Abele wrote:
On 01.10.2007, at 09:58, William A. Rowe, Jr. wrote:
...
I like the idea of adding a date to each news item, be it on
httpd.a.o,
or our www.apache.org. +1.
+1, see attached patch which adds dates to the index and download
pages (see changes to
On 10/02/2007 03:16 PM, Jim Jagielski wrote:
Comments?:
Looks fine to me.
Regards
Rüdiger
On 10/2/07, Jim Jagielski [EMAIL PROTECTED] wrote:
On Oct 1, 2007, at 6:52 PM, William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
Give that some thought :)
One thing I'm pondering is a 2.3.0 alpha in the near future.
If only to give the we stay back at version n.x-1 crowd
On Oct 2, 2007, at 2:36 PM, Jeff Trawick wrote:
On 10/2/07, Jim Jagielski [EMAIL PROTECTED] wrote:
On Oct 1, 2007, at 6:52 PM, William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
Give that some thought :)
One thing I'm pondering is a 2.3.0 alpha in the near future.
If only to give
Eric Covener wrote:
While the API might be a little ambiguous, and the caller can
explicitly set the timeout, is this a discrepancy APR should
eliminate?
I'm going to add the apr_file_pipe_timeout_set(foo, 0) call instead to
mod_ext_filter unless there are any objections.
+1
Jim Jagielski wrote:
On Oct 2, 2007, at 2:36 PM, Jeff Trawick wrote:
On 10/2/07, Jim Jagielski [EMAIL PROTECTED] wrote:
On Oct 1, 2007, at 6:52 PM, William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
Give that some thought :)
One thing I'm pondering is a 2.3.0 alpha in the near
On Oct 2, 2007 11:52 AM, Paul Querna [EMAIL PROTECTED] wrote:
So, the first step is to cut out any illusion that new features are
going into 1.3, with a statement like this:
Starting in January 2008, only critical security issues will be fixed in
Apache HTTP Server versions 1.3.x or 2.0.x.
On 10/02/2007 08:52 PM, Paul Querna wrote:
Jim Jagielski wrote:
On Oct 2, 2007, at 2:36 PM, Jeff Trawick wrote:
On 10/2/07, Jim Jagielski [EMAIL PROTECTED] wrote:
On Oct 1, 2007, at 6:52 PM, William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
Give that some thought :)
One thing I'm
Joe Orton wrote:
On Mon, Oct 01, 2007 at 02:22:11AM -0500, William Rowe wrote:
server/Makefile.in;
export_files:
tmp=export_files_unsorted.txt; \
rm -f $$tmp touch $$tmp; \
for dir in $(EXPORT_DIRS); do \
ls $$dir/*.h $$tmp; \
done; \
Jim Jagielski wrote:
On Oct 1, 2007, at 4:07 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
But, as I read it, the '*' in OPTIONS * does not really
mean a Location *... in other words, it's not a URI per se.
OPTIONS * asks for the capabilities of the server itself,
independent of
On Oct 2, 2007, at 2:52 PM, Paul Querna wrote:
So, the first step is to cut out any illusion that new features are
going into 1.3, with a statement like this:
Starting in January 2008, only critical security issues will be
fixed in
Apache HTTP Server versions 1.3.x or 2.0.x.
I honestly
Jim Jagielski wrote:
Comments?:
Just one;
Index: modules/http/http_core.c
===
--- modules/http/http_core.c(revision 581205)
+++ modules/http/http_core.c(working copy)
@@ -234,6 +234,24 @@
return OK;
}
+static
On Oct 2, 2007, at 12:23 PM, William A. Rowe, Jr. wrote:
The more I think about this, if Location * is supported at all it
should be the first-applied, global setting of any request, not just
OPTIONS * (there really is no reason for specific exceptions.)
For that matter LocationMatch .* IS
On Oct 2, 2007, at 3:32 PM, Roy T. Fielding wrote:
On Oct 2, 2007, at 12:23 PM, William A. Rowe, Jr. wrote:
The more I think about this, if Location * is supported at all it
should be the first-applied, global setting of any request, not just
OPTIONS * (there really is no reason for specific
On Oct 2, 2007, at 12:50 PM, Jim Jagielski wrote:
The current rec does that. Since * does not map to
any storage, or, in fact to any Location, it simply creates
the Allow from the server capabilities.
Allow only applies to URIs, not *. I have a fix for that.
Roy
Paul Querna wrote:
Starting in January 2008, only critical security issues will be fixed in
Apache HTTP Server versions 1.3.x or 2.0.x.
Actually that statement is too narrow; What if we publish a manifesto such
as this?
Apache httpd 1.3 to be retired at it's 10th anniversary
The Apache
Roy T. Fielding wrote:
I was only talking about the OPTIONS /path case. * is a special
case of a true null request -- it should only deal with server
capabilities and ignore Location/Directory configs.
Could you clarify, though? If PROPGET or PUT is supported on some
subset of the server
On Oct 2, 2007, at 1:34 PM, William A. Rowe, Jr. wrote:
Roy T. Fielding wrote:
I was only talking about the OPTIONS /path case. * is a special
case of a true null request -- it should only deal with server
capabilities and ignore Location/Directory configs.
Could you clarify, though? If
[EMAIL PROTECTED] wrote:
Log:
Reduce the last change to a minimum, since OPTIONS * does not
include an Allow header field (* is not a resource).
Ignore my previous question; obviously this makes it a non-issue.
very nice... do include the last paragraph :)
On 10/2/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Paul Querna wrote:
Starting in January 2008, only critical security issues will be fixed in
Apache HTTP Server versions 1.3.x or 2.0.x.
Actually that statement is too narrow; What if
On Tue, 2 Oct 2007 14:07:45 -0700
Roy T. Fielding [EMAIL PROTECTED] wrote:
On Oct 2, 2007, at 1:39 PM, Roy T. Fielding wrote:
Nope. * is not a resource. Since it is impossible to know the
mask of the entire resource space, HTTP does not require that
Allow be included on OPTIONS *
On Oct 2, 2007, at 1:39 PM, Roy T. Fielding wrote:
Nope. * is not a resource. Since it is impossible to know the
mask of the entire resource space, HTTP does not require that
Allow be included on OPTIONS * responses. Just committed a fix.
Hmm, I am still seeing an Allow header even after my
On 10/02/2007 10:36 PM, [EMAIL PROTECTED] wrote:
Author: fielding
Date: Tue Oct 2 13:36:47 2007
New Revision: 581374
URL: http://svn.apache.org/viewvc?rev=581374view=rev
Log:
Reduce the last change to a minimum, since OPTIONS * does not
include an Allow header field (* is not a
On Oct 2, 2007, at 4:39 PM, Roy T. Fielding wrote:
On Oct 2, 2007, at 1:34 PM, William A. Rowe, Jr. wrote:
Roy T. Fielding wrote:
I was only talking about the OPTIONS /path case. * is a special
case of a true null request -- it should only deal with server
capabilities and ignore
On Oct 2, 2007, at 5:07 PM, Roy T. Fielding wrote:
On Oct 2, 2007, at 1:39 PM, Roy T. Fielding wrote:
Nope. * is not a resource. Since it is impossible to know the
mask of the entire resource space, HTTP does not require that
Allow be included on OPTIONS * responses. Just committed a fix.
On Oct 2, 2007, at 5:15 PM, Ruediger Pluem wrote:
On 10/02/2007 10:36 PM, [EMAIL PROTECTED] wrote:
Author: fielding
Date: Tue Oct 2 13:36:47 2007
New Revision: 581374
URL: http://svn.apache.org/viewvc?rev=581374view=rev
Log:
Reduce the last change to a minimum, since OPTIONS * does not
[EMAIL PROTECTED] wrote:
Oh, last commit was supposed to say we need to return
DONE so we don't invoke any handlers.
Just so everyone here knows;
svn propset --revprop -r581388 svn:log Return DONE instead of OK to prevent any
further hooks from touching the non-URI OPTIONS * request
and it
Looks like an overloaded server to me. It is strange that there are so
many processes in 'R' state. This looks to me as some clients are
playing
games with your server by connecting it but not sending a request.
The thing is, as soon as apache is stop/started, the R's disappear- if it
was an
On Oct 2, 2007, at 2:21 PM, [EMAIL PROTECTED] wrote:
Author: jim
Date: Tue Oct 2 14:21:04 2007
New Revision: 581389
URL: http://svn.apache.org/viewvc?rev=581389view=rev
Log:
Ensure the URI is * and not something like *foo
I did not want that case to pass through, on purpose.
Roy
On 10/02/2007 11:21 PM, Jim Jagielski wrote:
On Oct 2, 2007, at 4:39 PM, Roy T. Fielding wrote:
On Oct 2, 2007, at 1:34 PM, William A. Rowe, Jr. wrote:
Roy T. Fielding wrote:
I was only talking about the OPTIONS /path case. * is a special
case of a true null request -- it should only
I don't see why we care, either way.
Roy
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
Just so everyone here knows;
svn propset --revprop -r581388 svn:log Return DONE instead of OK to
prevent any further hooks from touching the non-URI OPTIONS * request
and it appears we now get revprop commit messages! Hooray :)
You're
On Oct 2, 2007, at 2:15 PM, Ruediger Pluem wrote:
-if ((r-method_number != M_OPTIONS) || !r-uri || strcmp(r-
uri, *)) {
-return DECLINED;
+if ((r-method_number == M_OPTIONS) r-uri (r-uri[0]
== '*')) {
+return OK; /* Send HTTP pong, without Allow
header */
Apart from the fact that you have it's several times when you mean
its, +1
--
Rich Bowen
[EMAIL PROTECTED]
I would appreciate the active confirmation of this new parser by at
least a second set of eyeballs. We all know how notorious parsers
are at creating holes in the security of fresh software and code.
The relevant RFC is;
http://www.packetizer.com/rfc/rfc2428
(rfc.net appeared to be offline,
45 matches
Mail list logo
