Re: [VOTE] Release Apache HTTP server 2.2.11
Jorge Schrauwen jorge.schrau...@gmail.com wrote on 2008年12月17日, 19:07 For the early httpd-2.2.x series it has compiled on Win64. Then again it's very picky in which platform you use. Win XP x64 + VS2005/8 works best. Vista x64 is has some problems with platform SDK (not sure they are fix now). How long will they be compilable? I don't know. I think it has more to do with the makefile(s) than with the code it self. There seems to be a bug in the project updating functions of VS2005/08: embedded \ char's in the .rc files always made a fatal error to the resource compiler (rc.exe), e.g., ... LONG_NAME=Apache HTTP Server ... If all the inner \ are replaced with \' (namely, quot; to apos;), then the updated project files (.vcproj) will be OK to compile. Was this part of the problems with the makefile(s)? Bing
missing prefer-language on nested subrequests
I'm using content negotiation with type-maps and I'm having a problem when a subrequest does another subrequest - i.e. an #included document does another #include. On the first #include, 'prefer-language' is set correctly, so negotiation can pick the right language, but on the subsequent #include, 'prefer-language' is no longer set, and I get the default. I've been tracing and debugging trying to spot the problem, but I'm not really getting very far - I also don't know the internal apache structure very well, which is no doubt a hinderance. Can anyone here perhaps help me with where to look? thanks Per -- /Per Jessen, Zürich
Re: missing prefer-language on nested subrequests
Per Jessen wrote: I'm using content negotiation with type-maps and I'm having a problem when a subrequest does another subrequest - i.e. an #included document does another #include. On the first #include, 'prefer-language' is set correctly, so negotiation can pick the right language, but on the subsequent #include, 'prefer-language' is no longer set, and I get the default. I've been tracing and debugging trying to spot the problem, but I'm not really getting very far - I also don't know the internal apache structure very well, which is no doubt a hinderance. Can anyone here perhaps help me with where to look? I should have added that I'm running 2.2.11 on Linux. -- /Per Jessen, Zürich
Re: [VOTE] Release Apache HTTP server 2.2.11
Looks like you haven't run cvtdsp.pl to convert the vc6 dsp's to once that upgrade. There is a more detailed explenation here: http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64 ~Jorge On Thu, Dec 18, 2008 at 10:14 AM, Bing Swen bs...@pku.edu.cn wrote: Jorge Schrauwen jorge.schrau...@gmail.com wrote on 2008年12月17日, 19:07 For the early httpd-2.2.x series it has compiled on Win64. Then again it's very picky in which platform you use. Win XP x64 + VS2005/8 works best. Vista x64 is has some problems with platform SDK (not sure they are fix now). How long will they be compilable? I don't know. I think it has more to do with the makefile(s) than with the code it self. There seems to be a bug in the project updating functions of VS2005/08: embedded \ char's in the .rc files always made a fatal error to the resource compiler (rc.exe), e.g., ... LONG_NAME=Apache HTTP Server ... If all the inner \ are replaced with \' (namely, quot; to apos;), then the updated project files (.vcproj) will be OK to compile. Was this part of the problems with the makefile(s)? Bing
Re: proxy_ajp connect timeout fix.
Ruediger Pluem wrote: I guess you should move this over to d...@apr as this is likely a problem with the windows specific connect call not returning immediately. I moved this over to d...@apr as suggested, but have not received any responses there. Note that I applied Matt Stevenson's suggested fix from earlier in this thread [http://marc.info/?l=apache-httpd-devm=122358323701009w=2] and the connection timeout then worked on Windows as expected with 8 dead ports being checked in between 1 and 2 seconds -- which is what I'd expect given a connectiontimeout of 160ms. It would seem proxy_util.c should not have to do this but rather that whatever is needed to get connection timeouts to work on a given platform should be done in apr_socket_connect(). This raises another question, though. Earlier in this thread there were claims that Matt Stevenson's patch had adverse performance impacts, e.g. on HTTPS. Can someone explain how this could be? I ask in part as unless/until someone figures out the right fix in APR, I'll have to use Matt's patch -- and would like to understand the downsides and mitigate them if possible. -- Jess Holle
Revise VC6 .dsp files -- was: [VOTE] Release Apache HTTP server 2.2.11
Jorge Schrauwen wrote on 2008年12月18日 20:10 On Thu, Dec 18, 2008 at 10:14 AM, Bing Swen bs...@pku.edu.cn wrote: Jorge Schrauwen jorge.schrau...@gmail.com wrote on 2008年12月17日, 19:07 For the early httpd-2.2.x series it has compiled on Win64. Then again it's very picky in which platform you use. Win XP x64 + VS2005/8 works best. Vista x64 is has some problems with platform SDK (not sure they are fix now). How long will they be compilable? I don't know. I think it has more to do with the makefile(s) than with the code it self. There seems to be a bug in the project updating functions of VS2005/08: embedded \ char's in the .rc files always made a fatal error to the resource compiler (rc.exe), e.g., ... LONG_NAME=Apache HTTP Server ... If all the inner \ are replaced with \' (namely, quot; to apos;), then the updated project files (.vcproj) will be OK to compile. Was this part of the problems with the makefile(s)? Looks like you haven't run cvtdsp.pl to convert the vc6 dsp's to once that upgrade. There is a more detailed explenation here: http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64 ~Jorge I already read your nice tutorial there, and many thanks. But I just meant whether it is possible to just revise the makefiles (VC6 .dsp files) in the official httpd Win32 release package to make the updated Win64 project files directly compilable? Bing
Re: Revise VC6 .dsp files -- was: [VOTE] Release Apache HTTP server 2.2.11
IIRC there where problems with this. The update dsp doesn't compile clean on vc6. vc6 is still the compiler used for all office asf httpd binaries. ~Jorge On Thu, Dec 18, 2008 at 3:00 PM, Bing Swen bs...@pku.edu.cn wrote: Jorge Schrauwen wrote on 2008年12月18日 20:10 On Thu, Dec 18, 2008 at 10:14 AM, Bing Swen bs...@pku.edu.cn wrote: Jorge Schrauwen jorge.schrau...@gmail.com wrote on 2008年12月17日, 19:07 For the early httpd-2.2.x series it has compiled on Win64. Then again it's very picky in which platform you use. Win XP x64 + VS2005/8 works best. Vista x64 is has some problems with platform SDK (not sure they are fix now). How long will they be compilable? I don't know. I think it has more to do with the makefile(s) than with the code it self. There seems to be a bug in the project updating functions of VS2005/08: embedded \ char's in the .rc files always made a fatal error to the resource compiler (rc.exe), e.g., ... LONG_NAME=Apache HTTP Server ... If all the inner \ are replaced with \' (namely, quot; to apos;), then the updated project files (.vcproj) will be OK to compile. Was this part of the problems with the makefile(s)? Looks like you haven't run cvtdsp.pl to convert the vc6 dsp's to once that upgrade. There is a more detailed explenation here: http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64 ~Jorge I already read your nice tutorial there, and many thanks. But I just meant whether it is possible to just revise the makefiles (VC6 .dsp files) in the official httpd Win32 release package to make the updated Win64 project files directly compilable? Bing
Re: svn commit: r712611 - /httpd/httpd/trunk/docs/conf/extra/httpd-mpm.conf.in
On 29.11.2008 20:27, Rainer Jung wrote: pque...@apache.org schrieb: Author: pquerna Date: Sun Nov 9 21:48:21 2008 New Revision: 712611 URL: http://svn.apache.org/viewvc?rev=712611view=rev Log: Add Simple MPM to example mpm config. Submited by: Ryan Phillipsryan trolocsis.com Modified: httpd/httpd/trunk/docs/conf/extra/httpd-mpm.conf.in Modified: httpd/httpd/trunk/docs/conf/extra/httpd-mpm.conf.in URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/extra/httpd-mpm.conf.in?rev=712611r1=712610r2=712611view=diff == --- httpd/httpd/trunk/docs/conf/extra/httpd-mpm.conf.in (original) +++ httpd/httpd/trunk/docs/conf/extra/httpd-mpm.conf.in Sun Nov 9 21:48:21 2008 @@ -21,6 +21,15 @@ /IfModule /IfModule + +# Simple MPM +# SimpleProcCount: Number of child processes launched at server startup +# SimpleThreadCount: Set the number of Worker Threads Per-Process +IfModule mpm_simple_module +SimpleProcCount 5 +SimpleThreadCount 5 +/IfModule + # # Only one of the below sections will be relevant on your # installed httpd. Use apachectl -l to find out the You might want to flip the simple mpm block and the general mpm comment following it: Done in r727761.
Re: [VOTE] Release Apache HTTP server 2.2.11
Bing Swen wrote: Jorge Schrauwen jorge.schrau...@gmail.com wrote on 2008年12月17日, 19:07 For the early httpd-2.2.x series it has compiled on Win64. Then again it's very picky in which platform you use. Win XP x64 + VS2005/8 works best. Vista x64 is has some problems with platform SDK (not sure they are fix now). How long will they be compilable? I don't know. I think it has more to do with the makefile(s) than with the code it self. There seems to be a bug in the project updating functions of VS2005/08: embedded \ char's in the .rc files always made a fatal error to the resource compiler (rc.exe), e.g., ... LONG_NAME=Apache HTTP Server ... If all the inner \ are replaced with \' (namely, quot; to apos;), then the updated project files (.vcproj) will be OK to compile. Was this part of the problems with the makefile(s)? It's a bug in Visual Studio (already reported when we were meeting with the a couple Visual Studio development folks in Redmond)... the fix is pretty weird... srclib\apr\build\cvtdsp -2005 Now the resulting .dsp files can never be opened again in studio 5/6, but the quotes are shifted around for purposes of importing.
Re: [VOTE] Release Apache HTTP server 2.2.11
William A. Rowe, Jr. wrote Bing Swen wrote: There seems to be a bug in the project updating functions of VS2005/08: embedded \ char's in the .rc files always made a fatal error to the resource compiler (rc.exe), e.g., ... LONG_NAME=Apache HTTP Server ... If all the inner \ are replaced with \' (namely, quot; to apos;), then the updated project files (.vcproj) will be OK to compile. Was this part of the problems with the makefile(s)? It's a bug in Visual Studio (already reported when we were meeting with the a couple Visual Studio development folks in Redmond)... the fix is pretty weird... srclib\apr\build\cvtdsp -2005 Now the resulting .dsp files can never be opened again in studio 5/6, but the quotes are shifted around for purposes of importing. So is it a good idea to maintain two sets of project files to cope with this problem: one for the old VS 5/6 .dsp files (no more x64 support), and one for VS 2005/08 .vcproj files (with direct x64 support)? Bing
Re: [VOTE] Release Apache HTTP server 2.2.11
bing swen wrote: So is it a good idea to maintain two sets of project files to cope with this problem: one for the old VS 5/6 .dsp files (no more x64 support), and one for VS 2005/08 .vcproj files (with direct x64 support)? No, it's a horrid idea. It's a good idea to drop to one cross-platform reference file as apr has (config.layout), and spit out whatever the heck the user wants (visual studio .dsw, .sln, eclipse, codewarrior etc etc.) Right now windows users are treated to a gui perspective of httpd (which I'll state firsthand is an amazingly better way to become acquainted with the code base) while unix users stumble in makefile land of ./configure --help. But the number one problem at httpd builds has always been that the .dsp falls out of sync with makefile.in and config.m4, while the netware build is often not updated for half a year. That's what happens when we appeal to each special interest of their own unique build system. So my holiday project is to resolve apr for win32 from config.layout etc. (If Netware wasn't an orphaned platform, I'd even likely start replacing their files too, but I'll let someone interested in orphans start dealing with that). Once successful, going to look at doing the same over here. And likely will stick with config.m4 files as best as I can, since love them or hate them, they are what we are used to.
Re: mod_fcgid license questions
Hi, all
Sorry for the delay, I have track down all patches base on my ChangeLog( I
keep my mail archive), so here is my brief:
the Inside job
version 0.76 ( Jul 6th 2004 )
1. Code fix. Replace the depreciated BRIGADE_FOREACH macro, which compile
against httpd 2.1-Dev.
(Patch by Paul Querna(chip at force-elite.com))
Version2.1 ( Feb 15th 2007 )
3. Bug fix. Authoritative flag reversed
Thank Chris Darroch for the patch
---
Minor patches
...Ignore here, I attach a file to show every modification to every ChangeLog
entry. (If anyone think any change is major, please let me know)
Major patches
version 1.10 ( Jul 3rd 2006 )
1. Use poll() instead of select() in UNIX. It becomes problematic on apache2
with large number of logfiles. Apache2 calls poll() (when OS supports it), and
in that case it doesn't need to be recompiled with larger FD_SETSIZE. select()
is still limited to FD_SETSIZE.(Thank Piotr Gackiewicz gacek at intertele.pl
for the patch.)
2. Bug fix: Some requests fail with HTTP 500 and no errorlog entry is
generated (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
Version2.2 (Jul 31st 2007)
3. Support configuration TimeScore
Thank Tim Jensen for the patch.
(This is a patch from sourceforge.net:
https://sourceforge.net/tracker/download.php?group_id=174879atid=870993file_id=218023aid=1670268,
author is https://sourceforge.net/users/timjensen66/)
So, that mean there are other two people are involved.
Thanks
- Original Message -
From: Chris Darroch chr...@pearsoncmg.com
To: dev@httpd.apache.org
Sent: Thursday, December 18, 2008 1:20 PM
Subject: Re: mod_fcgid license questions
William A. Rowe, Jr. wrote:
How many are we talking about (in the significant category)? The
easiest way probably depends on how many people, how easy they are
to contact, etc.
Ryan, do you have a rough sense of this?
From my own review of the ChangeLog, it looks like there are
roughly about 10-12 major contributions by others (two of whom are
httpd committers). There are lots of additional people listed,
but these seem to divide up between minor patch contributions,
thanks for bug reports or for testing a bug fix, or thanks for
suggesting a possible new feature.
Clearly, though, we'll need Ryan to look through and identify
the major contributors.
I'd prefer that we simply sponsor this effort under the httpd PMC here
at our project.
We have to file an IP code clearance through the Incubator, but that's
relatively simple (and a good part is finished already now that the
appropriate paperwork is filed with the secretary).
Does anyone feel that the addition of mod_fcgid should be driven through
the incubator? Speaking first hand, it didn't resolve the shortcomings
of lack of community behind mod_aspdotnet, and didn't really give mod_ftp
the visibility it needed (and attracted once it graduated). So for most
existing modules, I don't think it solves many of the problems we might
or might not face here at httpd.
I really don't know all the options here, but from what you describe,
it sounds like a faster track to get the IP code clearance done would
be ideal, if possible. So, a +1 from me if this is feasible.
Thanks,
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
--
version 1.04 ( Dec 2nd 2004 )
1. Bug fix. ap_scan_script_header_err_core can return non OK without errors.
e.g. CGI outputs Last-Modified header and browser request with
If-Mofieided-Since header, ap_scan_script_header_err_core() may returns 302(Not
Modified)
(Thank Tatsuki Sugiura, sugi at nemui.org for the bug fix patch)
--- fcgid_bridge.c.orig 2004-11-11 09:40:17.0 +0900
+++ fcgid_bridge.c 2004-11-11 09:41:30.0 +0900
@@ -217,7 +217,7 @@
server_rec *main_server = r-server;
fcgid_command fcgi_request;
fcgid_bucket_ctx *bucket_ctx;
- int i, stopping;
+ int i, stopping, cond_status;
apr_status_t rv;
apr_bucket_brigade *brigade_stdout;
char sbuf[MAX_STRING_LEN];
@@ -330,11 +330,10 @@
bucket_ctx));
/*APR_BRIGADE_INSERT_TAIL(brigade_stdout,
apr_bucket_flush_create(r-connection-bucket_alloc)); */
- /* Check the script header first */
- if (ap_scan_script_header_err_core
- (r, sbuf, getsfunc_fcgid_BRIGADE, brigade_stdout) != OK) {
- return HTTP_INTERNAL_SERVER_ERROR;
- }
+ /* Check the script header first. If got error, return immediately */
+ if ((cond_status = ap_scan_script_header_err_core
+ (r, sbuf, getsfunc_fcgid_BRIGADE, brigade_stdout)) = 400)
+ return cond_status;
/* Check redirect */
location =
Re: [VOTE] Release Apache HTTP server 2.2.11
William A. Rowe, Jr. wrote: bing swen wrote: So is it a good idea to maintain two sets of project files to cope with this problem: one for the old VS 5/6 .dsp files (no more x64 support), and one for VS 2005/08 .vcproj files (with direct x64 support)? No, it's a horrid idea. Sorry for this. Since 2+ years have passed (since httpd-2.2.2, the last Win-x64 compilable version), I thought of some progress even at the cost of such complexity. It's a good idea to drop to one cross-platform reference file as apr has (config.layout), and spit out whatever the heck the user wants (visual studio .dsw, .sln, eclipse, codewarrior etc etc.) One more idea: would it sound good (not that complex) to put all the makefiles and build project files, and intermediate .obj files as well, into a separated top directory to maintain the purity of the source code? e.g., httpd-2.2.x /.../* official release files */ /build /netware /linux /windows /win32/Debug/*.obj /... /x64/Release/*.* /... All the build directive files use relative paths to the source files, and we give each platform a separate subdir under /build. Bing
Re: [VOTE] Release Apache HTTP server 2.2.11
Bing Swen wrote:
Sorry for this. Since 2+ years have passed (since httpd-2.2.2, the last
Win-x64 compilable version), I thought of some progress even at the cost
of such complexity.
Bing; in all fairness, 2.2.2 was the first version robust on windows, and
didn't yet build clean on x64. Blame any number of factors, but the bottom
line was that it was rushed and the handful of win32 folks hadn't been able
to keep up (much like the 2.3.0-alpha candidate --- the difference being,
it was an alpha ;-)
Actually I personally wish 2.2.0-2.2.2 were the end of the betas of 2.1.0
but that's water under the bridge. In any case I'm happy to see x.{odd}
versions go out that don't build under Platform X; if someone can be testing
and reviewing the next generation, that's good enough for me.
There are two flavors of complexity; the flavor you propose --- we hand
spin .dsw+.dsp, .sln+.vcproj, makefiles, and so on and so on and so on.
Guaranteed -1 This shit don't build on my platform!!! once it's in the
GA stable cycle, and little wonder. Change happens, and with multiple
ways of describing the build, they fall out of sync.
And there's another flavor of complexity, a build system that works just
about everywhere if someone is willing to put in the effort. That does
preclude autoconf, because it's impossible to handle all of the flavors
of m4 parsing behavior and shell script in a way that seamlessly works
for all target OS's, even though autoconf is a 80/20 solution. We get
regular reports of screwups in autoconf on the usual *$nix* platforms,
never mind oddballs (endianneSs in the most recent 2.2.10 tarballs come
to mind). But such things are non trivial problems, and if you have
the time, energy, funds or anything else to invest, consider the problem
solved.
Otherwise, please don't shoot the messenger.
.dsw+.dsp lets us provide everyone with a makefiles and Makefile.win that
works ***everywhere***. If you insist on a GUI, there is one extra step
for Visual Studio 2002 (.NET) - Visual Studio 2008 users. But would you
like that we provide you a Visual Studio 2008 project that VS 2005 users
can't even load - due to the fact that the MS VS team insists on breaking
the project description layout on every successive release?
As I said before, it's a non-trivial problem, and if you want to vent
please be our guest, and vent at the source of the problem, not we.
Yours,
Bill
