Is it correct for Apache to be executing includes when a HEAD request is
issued for a document that contains includes?
--
Jerry Baker
From: Jerry Baker [mailto:[EMAIL PROTECTED]]
Is it correct for Apache to be executing includes when a HEAD request
is
issued for a document that contains includes?
Yep. Apache treats a HEAD request exactly like a GET request, except
that we don't return the body. The HTTP spec states that
[EMAIL PROTECTED] wrote:
Modified:modules/generators mod_cgi.h
Log:
Once moved to a shared location, this bouncy #include dies
Revision ChangesPath
1.8 +1 -1 httpd-2.0/modules/generators/mod_cgi.h
@@ -59,7 +59,7 @@
#ifndef _MOD_CGI_H
#define
Hi Jim, Hi others,
there are still some open patches that I send in and have yet not been
commited, except the long standing src/helpers/install.sh issue.
I'm just wondering if this is to be commited for 1.3.25?
Open are patches to (send in 31 May):
* src/helpers/binbuild.sh
*
On Mon, Jun 10, 2002 at 11:46:46AM +0300, Zeev Suraski wrote:
What we need for efficient thread-safe operation is a mechanism like the
Win32 heaps - mutexless heaps, that provide malloc and free services on a
(preferably) contiguous pre-allocated block of memory. The question is
whether
On Mon, Jun 10, 2002 at 09:29:58AM -0700, Aaron Bannert wrote:
- creation (called once per server lifetime)
- malloc (called many times per request)
- free (called many times per request)
- end-of-request (called many times per request)
(Whoops, that should have been -- called
Initially I would think that a filter should see at most one EOS.
mod_ext_filter doesn't have logic to ignore subsequent ones, resulting
in a superfluous error message from a failed syscall when it tries to
re-do some cleanup when it hits a second EOS.
In this case, the subrequest is handled by
Does anyone have any answers here? Or am I asking this question
to the wrong list?
Thanks, Rob
-Original Message-
From: Rob Emanuele [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 3:27 PM
To: [EMAIL PROTECTED]
Subject: code sharing in authentication
I'm curious to the inner
From: [EMAIL PROTECTED] [mailto:trawick@rdu88-251-
Initially I would think that a filter should see at most one EOS.
mod_ext_filter doesn't have logic to ignore subsequent ones, resulting
in a superfluous error message from a failed syscall when it tries to
re-do some cleanup when it hits
On Mon, 10 Jun 2002, Rob Emanuele wrote:
I was wondering if they use each other or can use each other?
Can they share code? For example the mod_auth_digest module and
the mod_auth_mysql or mod_auth_dbm, can the latter modules make
use of the digest code?
As they're currently written, no,
Ryan Bloom [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] [mailto:trawick@rdu88-251-
Initially I would think that a filter should see at most one EOS.
mod_ext_filter doesn't have logic to ignore subsequent ones, resulting
in a superfluous error message from a failed syscall when it
From: [EMAIL PROTECTED] [mailto:trawick@rdu88-251-
Jeff Trawick [EMAIL PROTECTED] writes:
I suspect you're talking about this line of code which doesn't exist
in CVS:
Index: server/protocol.c
===
RCS file:
Ryan Bloom [EMAIL PROTECTED] writes:
void ap_finalize_sub_req_protocol(request_rec *sub)
{
-end_output_stream(sub);
+/* tell the filter chain there is no more content coming */
+if (!sub-eos_sent) {
+end_output_stream(sub);
+}
}
It probably
At 08:39 AM 6/9/2002, you wrote:
William A. Rowe, Jr. wrote:
Juergen,
Yes, Directory r: isn't even a path. Try Directory r:/. Same
for DocumentRoot. r: says The current working directory, on r: which
is absolutely meaningless for a service (and too vague for general
practice.)
At 04:08 AM 6/8/2002, Andi Gutmans wrote:
I just checked and it seems like Apache APR memory pools use mutex locking.
It'd be better to use functions like the Win32 ones which don't use mutex
locking (as we made sure that only one thread allocates from its pool).
This could be achieved by
While Allan Edwards and I were doing some testing of SSL we ran into a case
where we were able to send Apache into an infinite loop which eventually
consumed the machine's resources.
The problem occurs if you send a request to http://some.where.com:443; (instead
of https://some.where.com:443;.
I can't reproduce this. This test case is actually tested for in the
test suite. Which SSL library are you using? I was going off of the
assumption that the ap_discard_request_body() changes had broken this,
but since I have the most up-to-date code, I don't believe that the two
are related.
A while back I started working with the httpd sources in attempt to create
the missing code for POSTing over SSL when renegotiation is required. I
made the necessary changes, tested the code using several 1 to 30 megabyte
binary files, and it seems to work nicely.
The body is sucked up with
On Mon, Jun 10, 2002 at 04:20:06PM -0600, Nathan Friess wrote:
A while back I started working with the httpd sources in attempt to create
the missing code for POSTing over SSL when renegotiation is required. I
made the necessary changes, tested the code using several 1 to 30 megabyte
binary
Hi,
From http://www.xav.com/scripts/search/help/1068.html:
On the Apache web server, the last modified HTTP header is returned if
the HTML or SHTML file is executable. If the file has only read
permission, then no last modified information is returned.
If this is still the case, it
From: Cliff Woolley [mailto:[EMAIL PROTECTED]]
On Mon, 10 Jun 2002, Ryan Bloom wrote:
Please make sure that your code is up to date, because the server is
supposed to have logic that protects us from getting into an
infinite
loop.
Paul, I notice the line numbers in your back trace
On Tue, Jun 11, 2002 at 08:41:08AM +1000, Jie Gao wrote:
From http://www.xav.com/scripts/search/help/1068.html:
On the Apache web server, the last modified HTTP header is returned if
the HTML or SHTML file is executable. If the file has only read
permission, then no last
On Tue, Jun 11, 2002 at 08:41:08AM +1000, Jie Gao wrote:
Hi,
From http://www.xav.com/scripts/search/help/1068.html:
On the Apache web server, the last modified HTTP header is returned if
the HTML or SHTML file is executable. If the file has only read
permission, then no last
On Mon, Jun 10, 2002 at 06:52:52PM -0400, Paul J. Reder wrote:
I'm running with CVS head as of Friday morning with
OpenSSL 0.9.6b [engine] 9 Jul 2001 on Linux (RedHat 7.2).
rbb's changes went in on 2002/06/07 22:31:34 GMT. =)
You should update. -- justin
I'm running with CVS head as of Friday morning with
OpenSSL 0.9.6b [engine] 9 Jul 2001 on Linux (RedHat 7.2). I've
attached my httpd.conf, ssl.conf, and config.nice files.
I have been able to reproduce it on worker and prefork on two
different Linux boxes (both redhat 7.2).
All I do is
On Mon, 10 Jun 2002, Justin Erenkrantz wrote:
On Tue, Jun 11, 2002 at 08:41:08AM +1000, Jie Gao wrote:
Hi,
From http://www.xav.com/scripts/search/help/1068.html:
On the Apache web server, the last modified HTTP header is returned if
the HTML or SHTML file is executable. If
Hmmm, I missed them. I'm updating and building now, I'll have an answer shortly
after dinner.
Ryan Bloom wrote:
I'm running with CVS head as of Friday morning with
OpenSSL 0.9.6b [engine] 9 Jul 2001 on Linux (RedHat 7.2). I've
attached my httpd.conf, ssl.conf, and config.nice files.
I have been
On Monday, June 10, 2002, at 03:22 PM, Cliff Woolley wrote:
On Mon, 10 Jun 2002, Roy T. Fielding wrote:
I know of one existing bug in httpd that I would consider a
showstopper, if I were RM, due to the way APR handles time.
Are you going to tell me what it is? :)
If-Modified-Since
Jie Gao wrote:
This is quite ambiguous, but I think this is how it should read:
On the Apache web server, the last modified HTTP header is returned if
the file is an HTML file. If it is a SHTML (or processed by
mod_include), then the last modified header is only returned when
the SHTML file is
On Mon, 10 Jun 2002, Roy T. Fielding wrote:
If-Modified-Since doesn't work because an HTTP time based on
seconds x10 is being compared to a file modification time
based directly on microseconds.
I thought I fixed that already!? Oh boy, did the patch not get committed?
It might be
On Mon, 10 Jun 2002, Cliff Woolley wrote:
On Mon, 10 Jun 2002, Roy T. Fielding wrote:
If-Modified-Since doesn't work because an HTTP time based on
seconds x10 is being compared to a file modification time
based directly on microseconds.
I thought I fixed that already!? Oh boy, did
On Mon, 10 Jun 2002, Cliff Woolley wrote:
No, I committed a patch for this on May 8. It's still broken for you? In
HEAD? On Unix or Win32?
PS: See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8760 .
--Cliff
From: Justin Erenkrantz [EMAIL PROTECTED]
Sent: Monday, June 10, 2002 4:30 PM
On Mon, Jun 10, 2002 at 04:20:06PM -0600, Nathan Friess wrote:
A while back I started working with the httpd sources in attempt to
create
the missing code for POSTing over SSL when renegotiation is required. I
Bad news. I just finished running
cvs update -dP httpd-2.0;cd httpd-2.0;make distclean;buildconf;config.nice;make;make
install
and tested it. The same thing still happens with the config I referenced earlier.
Any other ideas?
Paul J. Reder wrote:
Hmmm, I missed them. I'm updating and
I don't have any ideas. I can't reproduce this problem though. I'll
keep debugging on my end. Cliff, this may take some time.
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St. [EMAIL PROTECTED]
San Francisco, CA
Once upon a time Nathan Friess shaped the electrons to say...
AFAIK, this situation isn't implemented yet for 2.x. Currently, the server
just returns a 'forbidden' response. There's a long comment in
modules/ssl/ssl_engine_kernel.c which explains it all. I'm running some
scripts which
AFAIK, this situation isn't implemented yet for 2.x. Currently, the server
Yes, I got hit by the clue stick from Cliff. This is a special case
where mod_ssl wants to empty its input.
P.S. core_request_config-bb shouldn't be used at all.
Oh, i see. May I ask for some general overview
If-Modified-Since doesn't work because an HTTP time based on
seconds x10 is being compared to a file modification time
based directly on microseconds.
I thought I fixed that already!? Oh boy, did the patch not get
committed?
It might be sitting in the PR waiting for somebody to test
Roy T. Fielding wrote:
I still think it is insane to multiply or divide every time we want to
use seconds. Not a showstopper, though.
Insane? Yep. But if we require sec resolution on some items I
don't see a way around it. It's much harder to go the other way :) :)
--
Jim Jagielski wrote:
Roy T. Fielding wrote:
I still think it is insane to multiply or divide every time we want to
use seconds. Not a showstopper, though.
Insane? Yep. But if we require sec resolution on some items I
don't see a way around it. It's much harder to go the other way :)
From: Cliff Woolley [mailto:[EMAIL PROTECTED]]
On Mon, 10 Jun 2002, Ryan Bloom wrote:
I don't have any ideas. I can't reproduce this problem though.
I'll
keep debugging on my end. Cliff, this may take some time.
Any progress? I *can* reproduce this and am looking at it. I
just a note on this, SSLOptions +OptRengotiate simulates what
s3_srvr.c:ssl3_get_client_certificate would do when calling
ssl_verify_cert_chain() with the certs presented by the client.
for whatever reason, when the cert chain is saved to the session cache,
the peer cert is removed from the
On Mon, Jun 10, 2002 at 05:55:01PM -0400, Cliff Woolley wrote:
Since we're not getting anywhere on the showstopper 304 issue, I'm
getting sick of putting this thing off any longer. Unless somebody speaks
up in the next hour or so, I'm tagging 2.0.37.
You sent me a note about the 304, but I
On Mon, 10 Jun 2002, Doug MacEachern wrote:
i'd be surprised if 'SSLOptions +OptRengotiate' actually ever worked for
anybody before this change, including the 1.3 based modssl which still has
this issue.
i take that back a bit, i'd be surprised if it worked for anybody using
netscape
Does somebody want to tell me which machine I should build the 2.0.37
tarball on so as to minimize the libtool-bustedness across platforms?
Stick with icarus even though it's running libtool 1.3.4?
--Cliff
45 matches
Mail list logo
