On Mon, 1 Oct 2007 14:55:57 +0530
Mohit_Garg01 [EMAIL PROTECTED] wrote:
Hi,
My application has an apache input filter which reads the large
amount of POST data at one go and writes on to the back end server.
We want that reads are maintained in chunks and then those chunks are
written
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
We are running a busy Apache/2.0.54 server on 2.6.9 kernel, that suddenly
becomes very slow- requests either time out, or it takes 10-20sec to serve a 1K
thumbnail.
It is somewhat correlated with load spikes, but not perfectly (by looking at
the bandwidth graph, it never happens during the low
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 $(EXPORT_DIRS_APR); do \
(ls $$dir/ap[ru].h $$dir/ap[ru]_*.h
Greetings,
To-do list item #1 for this week is upgrade to 2.2.6. When I was
waiting for the tar-ball to download, it occurred to me that it isn't
blindingly obvious *when* the update was published. There's no date on
the homepage (http://httpd.apache.org/) or on the download page
Boyle Owen wrote:
Might it be an idea for 2.2.7?
I like the idea of adding a date to each news item, be it on httpd.a.o,
or our www.apache.org. +1.
(Especially since the datestamps of our tarballs are several days prior
to each release).
On 10/1/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Boyle Owen wrote:
Might it be an idea for 2.2.7?
I like the idea of adding a date to each news item, be it on httpd.a.o,
or our www.apache.org. +1.
(Especially since the datestamps of our tarballs are several days prior
to each
On 10/01/2007 08:32 AM, Alec Matusis wrote:
We are running a busy Apache/2.0.54 server on 2.6.9 kernel, that suddenly
becomes very slow- requests either time out, or it takes 10-20sec to serve a
1K thumbnail.
It is somewhat correlated with load spikes, but not perfectly (by looking at
Have you checked without the MaxMemFree setting?
I raised MaxMemFree to 3100, we will have to wait for a few days, since it
does not happen every day.
Why do you use MaxMemFree with such a small value at all?
We are also running 2 twistd server processes on this machine that can take
up to
On 01.10.2007, at 09:58, William A. Rowe, Jr. wrote:
Boyle Owen wrote:
Might it be an idea for 2.2.7?
You can also get it from here for now:
http://projects.apache.org/projects/http_server.html
or as a feed:
http://projects.apache.org/feeds/rss/http_server.xml
I like the idea of adding a
On Mon, Oct 01, 2007 at 12:05:58AM +0100, Nick Kew wrote:
RFC2616 is clear that:
1. OPTIONS * is allowed.
2. OPTIONS can be proxied.
However, it's not clear that OPTIONS * can be proxied,
given that there's no natural URL representation of it (* != /*).
The Co-Advisor suite has a
On 10/1/07, Jim Jagielski [EMAIL PROTECTED] wrote:
I know Roy's already reported the proxy error as bogus, but I think
the OPTIONS * BUGZ report is also bogus. As a test, I assumed that
both www.apache.org and apache.webthing.com are reasonably configured
servers:
www.apache.org is using a
On Oct 1, 2007, at 12:34 AM, Boyle Owen wrote:
Is there a reason for the coyness or is it just an oversight, like
people who send out invites to parties with elaborate directions and
clip-art but forget to put the date?
PGP to the rescue! Just downloaded the release, and Safari preserves
On 10/01/2007 03:30 PM, Joshua Slive wrote:
On 10/1/07, Jim Jagielski [EMAIL PROTECTED] wrote:
I know Roy's already reported the proxy error as bogus, but I think
the OPTIONS * BUGZ report is also bogus. As a test, I assumed that
both www.apache.org and apache.webthing.com are reasonably
Hello,
Here's my second take at submitting these tests. Following Bill's
comments, I did some changes to remove the ambiguity.
These tests check that the directives inside LocationMatch,
Directory sections as well as .htaccess are taken into
account when processing internal subrequests. The
On Mon, 01 Oct 2007 16:43:57 +0200
Ruediger Pluem [EMAIL PROTECTED] wrote:
On 10/01/2007 03:30 PM, Joshua Slive wrote:
On 10/1/07, Jim Jagielski [EMAIL PROTECTED] wrote:
[summary of everyone]
No problem.
OK, it's actually applying the permissions of DocumentRoot.
It's also ignoring the
Nick Kew wrote:
RFC2616 tells us OPTIONS * is basically a simple HTTP ping,
which suggests it could be at a 'lower' level than authconfig
and always be allowed. If there is a reason to deny it,
that could be by means of something analagous to TraceEnable.
Insufficient.
If we configure
On Mon, 1 Oct 2007 16:14:14 +0100
Nick Kew [EMAIL PROTECTED] wrote:
RFC2616 tells us OPTIONS * is basically a simple HTTP ping,
which suggests it could be at a 'lower' level than authconfig
and always be allowed. If there is a reason to deny it,
that could be by means of something analagous
On Oct 1, 2007, at 12:02 PM, Nick Kew wrote:
On Mon, 1 Oct 2007 16:14:14 +0100
Nick Kew [EMAIL PROTECTED] wrote:
RFC2616 tells us OPTIONS * is basically a simple HTTP ping,
which suggests it could be at a 'lower' level than authconfig
and always be allowed. If there is a reason to deny it,
On Oct 1, 2007, at 11:14 AM, Nick Kew wrote:
On Mon, 01 Oct 2007 16:43:57 +0200
Ruediger Pluem [EMAIL PROTECTED] wrote:
On 10/01/2007 03:30 PM, Joshua Slive wrote:
On 10/1/07, Jim Jagielski [EMAIL PROTECTED] wrote:
[summary of everyone]
No problem.
OK, it's actually applying the
On Mon, Oct 01, 2007 at 06:08:13PM -, [EMAIL PROTECTED] wrote:
Author: niq
Date: Mon Oct 1 11:08:13 2007
New Revision: 581030
URL: http://svn.apache.org/viewvc?rev=581030view=rev
Log:
No change, but they won't let me have foo
(and ... this is the module with a function addit_dammit
Jim Jagielski wrote:
TRACE also does not/should not trace to the filesystem.
So, I think what we should do is use the existing
architecture and have a quick_handler that checks for
the OPTIONS * case and, if so, return DONE.
You can't ignore the vhost, and preferably would handle the
On Oct 1, 2007, at 2:17 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
TRACE also does not/should not trace to the filesystem.
So, I think what we should do is use the existing
architecture and have a quick_handler that checks for
the OPTIONS * case and, if so, return DONE.
You can't
On Oct 1, 2007, at 2:18 PM, Nick Kew wrote:
On Mon, 1 Oct 2007 14:12:44 -0400
Jim Jagielski [EMAIL PROTECTED] wrote:
Well, at least addit_dammit is descriptive :)
Aha, so the struct should've been called holdit_dammit!
:)
On Oct 1, 2007, at 2:33 PM, Jim Jagielski wrote:
On Oct 1, 2007, at 2:17 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
TRACE also does not/should not trace to the filesystem.
So, I think what we should do is use the existing
architecture and have a quick_handler that checks for
the
Jim Jagielski wrote:
Hmmm on 2nd thought, map_to_storage is likely the more logical
place.
The answer, of course, is with the next version of apache, to finish
abstracting out the filesystem at map_to_storage; where there is no
DocumentRoot / FilePathAlias (e.g. alias) to force some other
On 10/1/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
But I'm rather against breaking this in 2.2 to solve (what are, today)
configuration quirks. Let's get this right for 2.4 and call out the
change very clearly in (our overlong) CHANGES? I'm thinking of a new
second-priority category
Joshua Slive wrote:
On 10/1/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
But I'm rather against breaking this in 2.2 to solve (what are, today)
configuration quirks. Let's get this right for 2.4 and call out the
change very clearly in (our overlong) CHANGES? I'm thinking of a new
On Mon, Oct 01, 2007 at 12:05:41PM -0700, Roy T. Fielding wrote:
On Oct 1, 2007, at 11:02 AM, Jim Jagielski wrote:
TRACE also does not/should not trace to the filesystem.
So, I think what we should do is use the existing
architecture and have a quick_handler that checks for
the OPTIONS * case
On 10/1/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Joshua Slive wrote:
Should be in this, rather sparse file:
http://httpd.apache.org/docs/trunk/new_features_2_4.html
But it's not a feature-per say. It's a bugfix, so the name new_features
doesn't tell admins they have to adopt a
Jim Jagielski wrote:
Great! That's exactly what I needed to know.
So it seems to me that a map_to_storage to check for
the special case of '*' whereas present action for
all other URIs is the best course of action.
Provided it's vetted against the vhost (it is) and against location *
then
Joshua Slive wrote:
On 10/1/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Joshua Slive wrote:
Should be in this, rather sparse file:
http://httpd.apache.org/docs/trunk/new_features_2_4.html
But it's not a feature-per say. It's a bugfix, so the name new_features
doesn't tell admins
On Mon, Oct 01, 2007 at 03:22:34PM -0400, Jim Jagielski wrote:
On Mon, Oct 01, 2007 at 12:05:41PM -0700, Roy T. Fielding wrote:
On Oct 1, 2007, at 11:02 AM, Jim Jagielski wrote:
TRACE also does not/should not trace to the filesystem.
So, I think what we should do is use the existing
On Mon, Oct 01, 2007 at 02:30:30PM -0500, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
Great! That's exactly what I needed to know.
So it seems to me that a map_to_storage to check for
the special case of '*' whereas present action for
all other URIs is the best course of action.
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 how I read it.
There is no 'real' Location *
There's a
On sön, 2007-09-30 at 16:54 -0700, Roy T. Fielding wrote:
On Sep 30, 2007, at 4:05 PM, Nick Kew wrote:
RFC2616 is clear that:
1. OPTIONS * is allowed.
2. OPTIONS can be proxied.
However, it's not clear that OPTIONS * can be proxied,
given that there's no natural URL
this is something really worth pondering;
http://www.securityspace.com/s_survey/server_graph.html?type=httpdomaindir=month=200709servbase=YToyOntpOjA7czoxMzoiQXBhY2hlLzIuMC41OSI7aToxO3M6MTM6IkFwYWNoZS8xLjMuMzciO30=serv1=QXBhY2hlLzIuMi40
Give that some thought :)
Bill
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 for folks to start exploring
what needs to be fixed in the
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 during the
crash:
300 requests currently being
William A. Rowe, Jr. wrote:
this is something really worth pondering;
http://www.securityspace.com/s_survey/server_graph.html?type=httpdomaindir=month=200709servbase=YToyOntpOjA7czoxMzoiQXBhY2hlLzIuMC41OSI7aToxO3M6MTM6IkFwYWNoZS8xLjMuMzciO30=serv1=QXBhY2hlLzIuMi40
Give that some thought :)
Paul Querna wrote:
I'm not sure what we are supposed to think about?
Lots of people still use 1.3 for their own reasons, its not going to
hold me back on things I would like to do in 2.4 or 3.0.
Good point; maybe this is part of the issue, what we *already* do today
in 2.2 etc, vs. what
On 10/1/2007 at 4:52 PM, in message [EMAIL PROTECTED], William
A. Rowe, Jr. [EMAIL PROTECTED] 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
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 if the Client has asked for one.
Our proxy currently eats all
43 matches
Mail list logo
