Seems that mod_include can pass empty bucket brigades
down the filter chain. For instance if the first line in
an SSI is !--#include... then SPLIT_AND_PASS_PRETAG_BUCKETS
will pass an empty brigade as the first brigade.
This causes problems with the logic in mod_deflate which
attempts to bypass
Justin Erenkrantz wrote:
You should really take a look at the trunk. =)
This has been fixed for many months. -- justin
Ah, I see it now! Thanks for the quick feedback Justin.
Allan
man, how did I get so far behind on my email...
I'd like to see us get this into httpd 2.2 for the reasons
previously outlined and think we need to get the work underway
as quickly as possible to determine how extensive the changes
are going to be and how fast progress can be made.
First order of
William A. Rowe, Jr. wrote:
At 01:29 PM 11/24/2004, Cliff Woolley wrote:
On Wed, 24 Nov 2004, Justin Erenkrantz wrote:
I'm sick of all talk and no action. We tried this last year when we were
almost ready to branch APR 1.0 and all action on that front ceased
entirely for a YEAR. This time it's
Brad Nicholes wrote:
-1 as well. This is now causing compiler errors on NetWare. Please
revert this patch!
Can you provide an indication of exactly what broke so we
will know what to avoid in future. Or was the breakage
actually due to the the mod_cache problem reported
last night?
Thanks, Allan
Roy T. Fielding wrote:
whoa! -1
Was this even discussed on the list? You just changed the
entire module API and introduced a dozen potential security holes.
The precursor to this patch [PATCH] WIN64: httpd API changes
was posted 10/7 so I thought we had had suitable time for
discussion. I have
Joe Orton wrote:
The ap_r* changes are not safe: these functions return negative values
on error. Each and every int-size_t conversion needs to be carefully
checked for this kind of issue.
Good point. I will review closely this weekend.
Thanks, Allan
Mladen Turk wrote:
[snip]
Both apr and libhttpd has more then 100 of those
when /Wp64 is used, so IMO we would just hide the problems under
carpet if just casting every 64-32 warning found.
Agreed, hiding underlying problems is not acceptable.
I am trying to address the many warnings that a
Win64
This set of changes gets rid of most of the libhttpd
64bit warnings on Windows at the cost of several httpd
API changes. I defined AP_INT_TRUNC_CAST for use where
there are size mismatches with APR API's (those APR
API's will need to be updated in APR 2.0)
Comments before I commit?
Allan
-
Jeff Trawick wrote:
possible heresy
The first parameter to select() on Windows is actually ignored. We
should zap the logic that does the Unix-style computation of
listenmaxfd and just pass in INVALID_SOCKET or 0, and add a comment
that the value is ignored.
/possible heresy
No heresy, MSDN doc
Mladen Turk wrote:
That's true, but the strlen can never be int (negative).
The API is DWORD meaning 32 bit unsigned integer, so either
cast to API or no cast.
You are correct that for WriteConsole the cast should
have been DWORD - I will fix that, thanks
For TextOut and lstrcpyn the parameter is
Joe Orton wrote:
On Wed, Sep 22, 2004 at 06:21:31PM -, [EMAIL PROTECTED] wrote:
--- core.c 20 Sep 2004 20:12:20 - 1.286
+++ core.c 22 Sep 2004 18:21:29 - 1.287
@@ -2298,7 +2298,7 @@
-cmd-server-pathlen = strlen(arg);
+cmd-server-pathlen =
William A. Rowe, Jr. wrote:
At 02:37 PM 9/23/2004, Allan Edwards wrote:
aren't as picky as the MS compiler, since I haven't seen anyone else
complaining about this. They seem to reasonably assume that we aren't
going to have strings 4Gig long.
However, they have qword ints and qword size_t's
NormW wrote:
Compiling network_io/win32/sendrecv.c
### mwccnlm Compiler:
#File: network_io\win32\sendrecv.c
#
# 110: while (cur_len DWORD_MAX) {
# Error: ^
# undefined identifier 'DWORD_MAX'
That would be
-AP_DECLARE(long) ap_get_client_block(request_rec *r, char *buffer, apr_size_t bufsiz);
+AP_DECLARE(apr_ssize_t) ap_get_client_block(request_rec *r, char *buffer, apr_size_t
bufsiz);
Don't know why long was used here, but it causes a warning
for Windows IA64 build since long is 32 bits. I'm
I posted a companion patch to the apr list last night.
This patch against HEAD along with the apr patch get
the three core dlls cross compiling with Visual Studio 6
+ IA64 SDK. It addresses most /W2 warnings and fixes a
couple of bugs. I haven't looked at many of the modules
yet.
As I mentioned in
Has anyone attempted to build apr/apache for Windows 2003 Itanium?
First attempts to build using 2003 SDK and Visual Studio 6.0
gave a surprising number of type mismatch warnings, about 100
for apr/aprutil and around 80 for libhttpd. Need to comb through
these to see how many are real issues, but
Joe Orton wrote:
Wouldn't it be simpler to just check for a brigade containing just EOS
and do nothing for that case in the first place?
Yes I had considered that. The initial patch covered some pathological
cases but after having looked over the code some more I think the simpler
more efficient
Running ProxyPass with mod_deflate results in
an extraneous 20 bytes being tacked onto 304
responses from the backend.
The problem is that mod_deflate doesn't handle
the zero byte body, adds the gzip header and
tries to compress 0 bytes.
This patch detects the fact that there was no
data to
Cliff Woolley wrote:
I haven't looked at the entire context of this, but if you remove a bucket
(brigade_first(ctx-bb) from a brigade without deleting it and without
having any extra pointers to it, you'll leak memory.
Thanks for catching that! I'll replace APR_BUCKET_REMOVE with
a call to
William A. Rowe, Jr. wrote:
uh wrong. with /debug incremental yes is the default but you have
to pound it into the msdev's head. please fix/revert.
-# ... /dll /incremental:no /debug /machine:I386
/base:@os\win32\BaseAddr.ref,libhttpd.dll /opt:ref
+# ... /dll /debug /machine:I386
William A. Rowe, Jr. wrote:
+1, but which warning does 4163 quiet?
It quiets C4163: '_rotl64' : not available as an intrinsic
function' (see below) that gets generated as a result of
including the platform SDK. Picking up the platform SDK also
results in a couple of other warnings but this was the
William A. Rowe, Jr. wrote:
Ok, the .pdb changes are committed to apache-1.3 head, along with the
updated .mak/.dep files. If someone else would mind checking out and
validating the command line build (makefile.win), both Release and Debug,
I'd be much obliged.
Looks good to me.
Allan
Rather than WindowsSocketsWorkaround, why not WinUseWinsock1 or ??. It
would be better I think if the directive somehow indicated exactly what
it was doing (causing the winnt mpm to use the select/accept winsock1
calls rather than AcceptEx, a winsock2 call).
We're still usng winsock2 with this
Paul J. Reder wrote:
There is an entry in the STATUS file about adding regular expression
support for CacheEnable/CacheDisable, wouldn't regular expressions
provide this function and a whole lot more?
That could be the next step, did I hear a volunteer
step forward ;-)
probably. My opinion in this case isn't strong either. Actually I wanted to
exclude an oversight of the INIT_FLAG macro :)
OK, point taken, thanks for the feedback Andre!
Allan
+AP_INIT_TAKE1(WindowsSocketsWorkaround, set_sockets_workaround, NULL, RSRC_CONF,
+ Set \on\ to work around buggy Winsock provider implementations of certain VPN or
Firewall software),
+
hey, no need to double code. AP_INIT_FLAG exists ;-)
Well I guess that's just a matter of personal
Currently CachEnable foo / will configure mod_cache to cache all forward proxy
responses. Seems to me we want to be a little more granular than that.
The following patch will enable the use of e.g. CacheEnable foo http:
to signify that just HTTP content should be cached. It also will allow
William A. Rowe, Jr. wrote:
Just to summarize, there are three conditions we need to consider:
1) we hit the TransmitFile recycle bug many times in a row
2) we have encountered an incompatible firewall or VPN
3) the IP address has changed
You seem to have the failcases easily reproduced. Would
William A. Rowe, Jr. wrote:
This patch can't be applied... it actually introduces a denial of service
problem if folks can simply early-disconnect a server some half dozen
actually 100 :)
times in a row... It isn't hard to work up such a tool.
If it is possible for someone to externally tickle
As far as I can tell this is a bug in the Sprint
PCS Connect support for AcceptEx, (they install a
Winsock transport provider called BMI). However, it slips
through our checks and causes the accept thread to
hard loop and consume most of the cpu.
What happens is that in get_listeners_from_parent()
Bill Stoddard wrote:
Humm... how do our friends at MS solve this in IIS?
It only happens because of our parent-child process
model. If you run -X the problem goes away. It's the
socket duplication that seems to bite us.
Allan
Perhaps we need a winnt mpm directive to force the server to use the
Win9* accept code path. Whould be a terrible thing to do on a production
level server (for performance reasons) but quite okay for most of the
folks that are seeing personal firewalls collide with our use of AcceptEx.
mmm...
Without this I believe Win98/ME are broken
on HEAD and APACHE_2_0_BRANCH. OK to commit?
Allan
Index: core.c
===
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.225.2.1
diff -u -d -b -r1.225.2.1 core.c
--- core.c
I suggest we cwd to the server root on startup. We can do this
in the winnt_mpm, or for all platforms in main(). Opinions?
+1 - at least for Windows
And +1 for the rest, or was that simply +0 to do so in main()?
why would we want to chdir() for the other platforms? maybe
In 1.3 we did not need to specify a drive letter
for ServerRoot and DocumentRoot paths but in 2.0
it appears we must specify the drive letter or Apache
will not start as a service. (note: the 2.0.36 .msi
install sets the drive letter so this limitation is
not immediately apparent to those
If your cwd is on another
volume, that's a problem. This hurts services, since the cwd will
always be c:\winnt\system32\.
Yep, was installed on a non-C: drive
I suggest we cwd to the server root on startup. We can do this
in the winnt_mpm, or for all platforms in main(). Opinions?
+1
I'm not going to finish it because:
a) I'm not really sure what to do on Win32.
main.c(617) : error C2065: 'SIGHUP' : undeclared identifier
main.c(620) : error C2065: 'AP_SIG_GRACEFUL' : undeclared identifier
main.c(628) : warning C4013: 'kill' undefined; assuming extern returning int
Error
Doesn't the new function need to be done before we hit ap_mpm_run()?
ap_run_rewrite_args gets called before ap_mpm_run in main().
If main() doesn't know what's going on then how would it work?
I was talking about putting the bit that didn't compile
on windows in the unix mpm, mainly the
Let me just go on record saying that I don't think we're in a
position to release another version.
I'll second that based on problems I still see
with filters - additional post coming momentarily.
Allan
A simple SSI file with two #include file directives
will coredump due the fact that we are copying the
filter chain *pointers* from the main request to
the subrequest in make_sub_request. When we add
the subreq_core_filter this corrupts the main
filter chain.
We need to copy the filter chain,
The other thing is that we actually want to use the exact same filters.
My patch replaces the ap_filter_t structures from the original
chain with exact copies in the subreq chain so 1) we have the
exact same filter chain and 2) and adds/removes will only affect
the subrequest chain.
That
I found the source of the bug. The SUB_REQ filter is an HTTP_HEADER
filter, but it shouldn't be. That is a resource filter, because it is
only added when the resource changes.
Yes, that's what I just saw and is the source of
at least one of the bugs I've been hitting. I
eagerly await your
Did that patch fix the bug for everybody? If so, I want to commit it.
I have a three hour meeting now, so I'm not going to have time to
though. Can somebody else commit it this afternoon if it works?
Thanks Ryan, with your patch we longer trap in the SSI testcase but
I have a question. In
My only other observation is that any filters added in the subreq
must only be added to the top of the rnew-output_filters
chain or must be cleanly removed before the subreq returns
otherwise the main chain will get corrupted. I haven't seen
this happen so far, so maybe this is just a
Jerry,
I've been trying to nail this one for a while now but have
not been able to recreate - do you have a testcase that will
generate the questionable POST request? What is catching the POST
on the server - a CGI? What platform is the server?
Please send any further info to me
Please don't let two mis-behaved modules color your judgment on this.
Both proxy and perchild must be re-written if they are going to be
clean, and once that is done the stupid set_module_config can be
removed. In fact, the server ran for over a day without the
set_module_config, but that
The real solution is to pass the core_net_rec structure to the NET_TIME
filter as user-data for the filter, the same way we do for CORE_IN and
CORE_OUT.
But you'll have to play some sort of trick to do that since the
NET_TIME filter is added from the create_request hook which does
not know
prevent any other module from running it's own net_time hook.
I meant net_time filter...
This might also be a problem on unix but I haven't tested.
When cgi's are launched a window sometimes pops up, same for
mod_include exec cgi. Is there a reason we are not
launching the cgi as a detached process?
Index: mod_cgi.c
50 matches
Mail list logo
