On Thu, Mar 18, 2004 at 10:29:39AM -0800, Aaron Bannert wrote:
On Mon, Mar 15, 2004 at 09:13:45AM +0100, Philippe Marzouk wrote:
On Sun, Mar 14, 2004 at 05:27:16PM -0800, Aaron Bannert wrote:
This sounds reasonable to me, did it ever get committed?
I imagine you asked the flood
Stas Bekman wrote:
Rodent of Unusual Size wrote:
Stas Bekman wrote:
does this make any difference/
perl Makefile.PL -apxs K:/Coar/Apache/Server-1.3/bin/apxs.pl -httpd
K:/Coar/Apache/Server-1.3/bin/Apache.exe
yes, it made a difference -- but it still didn't work. it now
specifies
Geoffrey Young wrote:
Stas Bekman wrote:
Rodent of Unusual Size wrote:
Stas Bekman wrote:
does this make any difference/
perl Makefile.PL -apxs K:/Coar/Apache/Server-1.3/bin/apxs.pl -httpd
K:/Coar/Apache/Server-1.3/bin/Apache.exe
yes, it made a difference -- but it still didn't work. it now
Hi,
I wonder if anyone has the same problem that the 32bit version
(-xarch=v8plus) works ok and the 64bit version (-xarch=v9) inhibits some
pronlem(s).
What I noticed is that /status displays the last number of requested URIs
just fine with the 32bit version but forgets about some requests (note
Andre Breiler wrote:
What I noticed is that /status displays the last number of requested URIs
just fine with the 32bit version but forgets about some requests (note
counter is right) in the 64bit version.
I'm not sure what is getting forgotten.
Is the detailed (extended status) table truncated?
Didn't we decide in the move to 2.0 that all directives would take an
argument? Win32DisableAcceptex seems to work just by being present in the
config with no argument. Shouldn't it instead be
Win32DisableAcceptex on|off
Joshua.
Roy T. Fielding wrote:
Ugg... fix_hostname() in 1.3.30-dev (and previous) are
broken such that it does *not* update parsed_uri with
the port and port_str value from the Host header.
This means that with a request like:
% telnet localhost
GET / HTTP/1.1
Host:
Joshua Slive wrote:
Didn't we decide in the move to 2.0 that all directives would take an
argument?
Maybe I wasn't paying attention.
Win32DisableAcceptex seems to work just by being present in the
config with no argument.
True.
Shouldn't it instead be Win32DisableAcceptex on|off
To be more
On Mon, 22 Mar 2004, Bill Stoddard wrote:
Joshua Slive wrote:
Didn't we decide in the move to 2.0 that all directives would take an
argument?
Maybe I wasn't paying attention.
As far as I know, there are no other directives in httpd-2.0 that act this
way. But I may be mistaken.
* Bill Stoddard [EMAIL PROTECTED] wrote:
Joshua Slive wrote:
Didn't we decide in the move to 2.0 that all directives would take an
argument?
Maybe I wasn't paying attention.
Win32DisableAcceptex seems to work just by being present in the
config with no argument.
True.
At 08:42 AM 3/22/2004, Bill Stoddard wrote:
Shouldn't it instead be Win32DisableAcceptex on|off
To be more consistent with EnableSendFile on|off, et. al? Hadn't considered that but
it makes sense.
or easier to parse and consistant w/ mmap/sendfile;
EnableWin32AcceptEx on|off [default: on if
William A. Rowe, Jr. wrote:
At 08:42 AM 3/22/2004, Bill Stoddard wrote:
Shouldn't it instead be Win32DisableAcceptex on|off
To be more consistent with EnableSendFile on|off, et. al? Hadn't considered that but it makes sense.
or easier to parse and consistant w/ mmap/sendfile;
I think I finally found the culprit. At first I thought it was the
core_output_filter, but it turns out that emulate_sendfile (incorrectly)
assumes that it is at the beginning of the file even when it's not.
The attached patch works here when I have the combo of buckets as
described below. The
stoddard2004/03/22 10:51:29
--- mod_rewrite.dsp 23 May 2003 02:47:50 - 1.21
+++ mod_rewrite.dsp 22 Mar 2004 18:51:29 - 1.22
-# ADD LINK32 kernel32.lib /nologo /subsystem:windows /dll /incremental:no /debug
/machine:I386 /out:Release/mod_rewrite.so
Now that 2.0.49 is out is there an estimated time of arrival for 1.3.30?
--
Jess Holle
On Tue, 23 Mar 2004, Bojan Smojver wrote:
I think I finally found the culprit. At first I thought it was the
core_output_filter, but it turns out that emulate_sendfile (incorrectly)
assumes that it is at the beginning of the file even when it's not.
The attached patch works here when I have
Bojan Smojver wrote:
I think I finally found the culprit. At first I thought it was the
core_output_filter, but it turns out that emulate_sendfile (incorrectly)
assumes that it is at the beginning of the file even when it's not.
The attached patch works here when I have the combo of buckets as
On Mon, 22 Mar 2004, Bill Stoddard wrote:
I took a 15 second look at the patch and have a concern (perhaps
unfounded). apr_file_seek() is probably an expensive operation. If
offset is 0, then in almost all cases (correct me if i'm wrong) the
fileptr will be at offset 0 as well, right? So
On Tue, 2004-03-23 at 07:48, Bill Stoddard wrote:
I took a 15 second look at the patch and have a concern (perhaps unfounded).
apr_file_seek() is probably an
expensive operation. If offset is 0, then in almost all cases (correct me if i'm
wrong) the fileptr will be at
offset 0 as well,
Hi All,
I have an application using apache 1.x on Linux AS30. When I start apache using ./apachectl start or startssl, it works fine. If i try to run apache in debug mode i.e. httpd -X, then my application gives following error:
[EMAIL PROTECTED] bin]$ ./apachectl start[Tue Mar 23 05:13:54 2004]
g g wrote:
[EMAIL PROTECTED] bin]$ ./apachectl start
[Tue Mar 23 05:13:54 2004] [warn] Loaded DSO /home/app6/abc.so uses
plain Apache 1.3 API, this module might crash under EAPI! (please
recompile it with -DEAPI)
The above line is probably what is wrong - your module needs to be
compiled with
Please have a look at the attached file.
--- Trend GateLock [EMAIL PROTECTED] (higp1.gatelock.com.tw)
** your_letter.pif
Trend GateLock [EMAIL PROTECTED] (higp1.gatelock.com.tw)
** your_letter.pif WORM_NETSKY.D
On Tue, 2004-03-23 at 07:48, Bill Stoddard wrote:
I took a 15 second look at the patch and have a concern (perhaps unfounded).
apr_file_seek() is probably an
expensive operation.
I've had a quick look at apr_file_seek() function and the cost depends
on how the file is opened. If it's
On Tue, 2004-03-23 at 12:40, Bojan Smojver wrote:
I did two quick benchmarks with sendfile() support turned off in order
to determine rough impact of the patch on emulate_sendfile() and the
whole of Apache (prefork MPM).
Just did another set of runs on the same machine (this time 100,000
At 03:42 PM 3/22/2004, Bojan Smojver wrote:
You are correct, it is probably an expensive operation. The other way
would be to know the position within a file and compare it to the one
that we should go to. If they are the same, do nothing.
I smell future bugs brewing - remember the handle may be
Yeah, it doesn't look good. The best I could come up with so far is the
apr_file_seek() every time. At least we know where we going to end up.
On Tue, 2004-03-23 at 14:19, William A. Rowe, Jr. wrote:
At 03:42 PM 3/22/2004, Bojan Smojver wrote:
You are correct, it is probably an expensive
27 matches
Mail list logo
