Re: No quadratic allocators (was Re: [RELEASE CANDIDATE] libapreq 1.34-RC2)
After going too long without any tuits, I've gotten around to properly
testing this. Looks ok, although I didn't really do anything
in-depth. - I'm going to commit and roll another RC.
Issac
Joe Schaefer wrote:
Joe Schaefer [EMAIL PROTECTED] writes:
Issac Goldstand [EMAIL PROTECTED] writes:
The apreq developers are planning a maintenance release of
libapreq1. This version primarily addresses an issue noted
with FireFox 2.0 truncating file uploads in SSL mode.
Please give the tarball at
http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz
a try and report comments/problems/etc. to the apreq-dev list
at [EMAIL PROTECTED]
+1, tested on Debian stable i386.
Having looked over some recent literature on memory allocation
attacks, I'm changing my vote to -1. We need to fix the
crappy quadratic allocator in multipart_buffer_read_body.
Here's a first stab at it- completely untested (I didn't even
bother trying to compile it). The strategy here though is to
allocate (more than) twice the amount last allocated, so the
total amount allocated will sum (as a geometric series) to
no more than 2 times the final allocation, which is O(n).
The problem with the current code is that the total amount
allocated is O(n^2), where n is basically the number of packets
received. This is entirely unsafe nowadays, so we should not bless
a new release which contains such code.
Index: c/apache_multipart_buffer.c
===
--- c/apache_multipart_buffer.c (revision 531273)
+++ c/apache_multipart_buffer.c (working copy)
@@ -273,17 +273,25 @@
return len;
}
-/*
- XXX: this is horrible memory-usage-wise, but we only expect
- to do this on small pieces of form data.
-*/
char *multipart_buffer_read_body(multipart_buffer *self)
{
char buf[FILLUNIT], *out = ;
+size_t nalloc = 1, cur_len = 0;
-while(multipart_buffer_read(self, buf, sizeof(buf)))
- out = ap_pstrcat(self-r-pool, out, buf, NULL);
+while(multipart_buffer_read(self, buf, sizeof(buf))) {
+size_t len = strlen(buf);
+if (len + cur_len + 1 nalloc) {
+char *tmp;
+nalloc = 2 * (nalloc + len + 1);
+tmp = ap_palloc(self-r-pool, nalloc);
+strcpy(tmp, out);
+out = tmp;
+}
+strcpy(out + cur_len, buf);
+cur_len += len;
+}
+
#ifdef DEBUG
ap_log_rerror(MPB_ERROR, multipart_buffer_read_body: '%s', out);
#endif
[RELEASE CANDIDATE] libapreq 1.34-RC3
The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Additionally, the memory allocation algorithm for multipart requests has been improved. Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC3.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] Thanks, Issac
Re: httpd 1.3 / 2.0 / 2.2 tags this weekend?
William A. Rowe, Jr. wrote:
I'd like to see new tarballs rolled soonish, given the single significant
bug that was disclosed earlier today.
Obviously most mass-vhosters are capable of compiling their own binary,
so providing the seperate-pid-table patch (whoever gets around to writing
one) resolves any immediate urgency.
I don't believe its a critical security issue -- if you can run code on
the server, as the server process, we can't defend against it. This
seems to me like a battle line firmly in the scripting languages land.
Anyways, until we have a patch that we can consider, I'm in no hurry.
On APR{,-Util}: Likely a good idea anyways.
-Paul
Apache2 mod_ssl with HSM support
Hello, I'd like to start a discussion about Hardware Security Module (HSM) support for mod_ssl. You may know that OpenSSL supports different HW engines. There is also support for PKCS#11 devices, a standard for communication with crypto devices - e.g. HSMs or Smartcards. Some HSM vendors support mod_ssl and their HSM with a modified OpenSSL/mod_ssl version. But support is limited to 1.3.X versions of Apache as far as we know. There seems to be no standard interface for mod_ssl with HSM support for private key protection and operations. We decided to extend mod_ssl for usage with an HSM. We have a first prototype (prealpha) with limited functionality now. The limitations: - Supports only one virtual host - Supports no keys from files at the moment - Loads HSM PIN from the OpenSSL.cnf file (No handler implemented at the moment) - Certificate comes from file (not really a limitation...) What it does: - Private key is no longer in a file, it's in the secure HSM store - Private key operations are processed on the HSM The HSM configuration happens in the OpenSSL.cnf file. In httpd_ssl.conf we introduced two additional parameters. Path to the OpenSSL config (Module global): SSLEngineConfig C:/Apache22/conf/openssl.cnf Reference describing the private key (Per virtual host): SSLCertificateKeyReference pkcs11#slot_0-id_65A0A10FFCE5B514CC228640C85373BB92C2DCD4 The reference descriptor has the following format: engineName#keyIdentifier engineName refers to the engine defined in openssl.cnf. The keyIdentifier part depends on the engine referred before. This two chunks are separated with '#'. In the sample above we address a PKCS#11 device and use the private key with id 65A0A10FFCE5B514CC228640C85373BB92C2DCD4 on slot 0. A sample file of the OpenSSL config is attached at the end of this post. Is it of interest to add HSM support to mod_ssl for private key protection in further versions of mod_ssl? Is there already an intention to implement this? If it is of interest and there are no plans to implement support, it would be great to have a discussion here how to do that. Kind regards Dan OpenSSL config file: # PKCS11 engine config## openssl_conf = openssl_def [openssl_def] engines = engine_section [engine_section] pkcs11 = pkcs11_section [pkcs11_section] engine_id = pkcs11 dynamic_path = C:\\Apache22\\bin\\engine_pkcs11.dll MODULE_PATH = C:\\Programme\\Eracom\\ProtectToolkit C SDK\\bin\\hsm\\cryptoki.dll PIN = 11223344 init = 0
Re: client timeout behavior.
On 05/29/2007 08:42 PM, Andy Wang wrote: We noticed that with mod_proxy_ajp, it's not possible to set an indefinite timeout like was possible with mod_jk. So a long running JSP page, for example: % Thread.sleep(96); % With mod_proxy_ajp timeout set to 300 will cause a 503 to be thrown back to the client since mod_proxy_ajp's timeout gets triggered. Two questions 1) Is there a way to force an indefinite timeout for mod_proxy_ajp like mod_jk has? With mod_jk, if the worker's timeout was set to 0 it will wait indefinitely Currently not, but there is no upper limit for the timeout. So I guess setting it to 86400 (1 day) should solve your problem for the moment. 2) how is it that the client doesn't time out? My firefox client has network.http.keep-alive.timeout set to 300. Wireshark doesn't show any keepalive traffic sent back and forth between apache and the client in between the request and the 503 response. I'm probably reading this wrong, but according to the KeepAliveTimeout documentation: The number of seconds Apache will wait for a subsequent request before closing the connection. Once a request has been received, the timeout value specified by the |Timeout http://httpd.apache.org/docs/2.2/mod/core.html#timeout| directive applies. First of all do not confuse Timeout and KeepAliveTimeout. They are completely different things. In my request to the Thread.sleep JSP page, the request was already made. Shouldn't the standard Timeout (300s in my case) apply and disconnect the client? The standard timeout applies, but in your case httpd is not waiting for an event that times out with this timeout. Timeout is the number of seconds httpd tries to send data *to* the client until it gives up and assumes the client / network to the client has died. But in your case httpd is waiting for a response *from* your servlet engine. So in this case the timeout you set for the ajp worker applies which I guess is set very high in your case given your first question. Regards Rüdiger
Re: Apache2 mod_ssl with HSM support
That would definitely be a good thing. More and more servers are using a HSM, and we only can suggest to our customers who want to do so to use a commercial server like IIS. Marc
Re: [Issue] External links @ the wiki, aka pagechange wars
On 5/23/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: We have a serious issue to determine, and I've asked for a 48 hour cooldown of wiki.apache.org/httpd/ to make a decision, and in the meantime asked that the wiki become read-only for the conclusion of this decision. [ ] Our httpd wiki is open to external resources for httpd. [ ] External httpd resources are prohibited. I mean this explicitly, obviously a link to MS/Sun/RedHat about their specific platform would be genuinely useful and relevant. I'm asking about askapache's external links, which have not been actually contributed to the foundation. And we've never presumed that pointers to external links are resources under the AL. AskApache and megaspaz decided to start a pagechange war tonight, but the first point is to decide if such external 'helpful pages' are welcome. If so, AskApache was in the right, if not, megaspaz is right. Either way, I immediately asked for infra to shutter the wiki to write access until this was resolved as a matter of POLICY. Once we determine a policy, I belive we owe megaspaz and AskApache a second chance once they are informed of the definative policy. Future wiki abuse would, of course, lead to account and IP blockage. But I believe at this moment both acted in best-faith without any guidance from our project, and we need to have policies so folks can be responsible wiki users. This isn't the end-all of all possibilities, but let's discuss for 2 days and reopen the wiki with a concrete policy? On 5/23/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: We have a serious issue to determine, and I've asked for a 48 hour cooldown of wiki.apache.org/httpd/ to make a decision, and in the meantime asked that the wiki become read-only for the conclusion of this decision. [ ] Our httpd wiki is open to external resources for httpd. [ ] External httpd resources are prohibited. I mean this explicitly, obviously a link to MS/Sun/RedHat about their specific platform would be genuinely useful and relevant. I'm asking about askapache's external links, which have not been actually contributed to the foundation. And we've never presumed that pointers to external links are resources under the AL. AskApache and megaspaz decided to start a pagechange war tonight, but the first point is to decide if such external 'helpful pages' are welcome. If so, AskApache was in the right, if not, megaspaz is right. Either way, I immediately asked for infra to shutter the wiki to write access until this was resolved as a matter of POLICY. Once we determine a policy, I belive we owe megaspaz and AskApache a second chance once they are informed of the definative policy. Future wiki abuse would, of course, lead to account and IP blockage. But I believe at this moment both acted in best-faith without any guidance from our project, and we need to have policies so folks can be responsible wiki users. This isn't the end-all of all possibilities, but let's discuss for 2 days and reopen the wiki with a concrete policy? If a Wiki isn't open to community input ( where community here means *users*, not the typical Apache definition of community meaning the *committers*), then what is it for? Committers can already post to the project website itself, so they do not need any extra mechanism to describe things that might be interesting. Content from users, on the other hand, can be either solicited (in which case external links are perfectly ok) or censored (in which case nobody need bother ... they can publish their own links on their own blogs, and let Google help information seekers instead of the ASF helping them). In the Apache projects I'm involved with, the only thing we kick off of the wiki pages is spam. It's a wiki ... it's user contributed content, and not necessarily reflective of the opinions of the project's developers. But it is *incredibly* useful to the users of the software we build. Deal with that reality ... or close it down ... your choice. Bill
Re: [Issue] External links @ the wiki, aka pagechange wars
Paul Querna wrote: William A. Rowe, Jr. wrote: We have a serious issue to determine, and I've asked for a 48 hour cooldown of wiki.apache.org/httpd/ to make a decision, and in the meantime asked that the wiki become read-only for the conclusion of this decision. [XXX] Our httpd wiki is open to external resources for httpd. [ ] External httpd resources are prohibited. I mean this explicitly, obviously a link to MS/Sun/RedHat about their specific platform would be genuinely useful and relevant. I believe that Wikis must be able to link to external sites -- just like we do in the regular documentation. However, just like the the regular documentation, these links are generally restricted to Vendors, or other long standing and stable sites. (or... example.com) He has quoted the Apache wiki etiqutte guide, in his home page on the wiki. Wiki Eitquette -- http://wiki.apache.org/httpd/WikiCourse/BasicIntroduction/200_Wikiquette?action=printmedia=projection His wiki Home Page -- http://wiki.apache.org/httpd/AskApache In which he infers he is allowed to use external links to materials of his own choice. However the wiki-etiquette seems to be a standard set of pages shipped with MoinMoin, maybe they need reviewing for ASF application and either removing, or modifying accordingly. I believe we can look to wikipedia's linking policy as a good example of how to build a 'policy' that people can understand: http://en.wikipedia.org/wiki/Wikipedia:External_links In this case: AdSense covered personal blogs especially from people who do not contribute in other mediums doesn't seem like a good place to be linking to. On the revision war: I don't like it; I do believe AskApache's link should be removed. I don't blame megaspaz, he was using the tools available, trying to communicate with AskApache that the link was unacceptable. The larger problem is that the AskApache person has never, AFAIK, made themselves known on the mailing list, or other mediums, making it impossible to communicate with them in other manners. AskApache has had several email conversations with both myself, and Rich. In which he was asked politely, but firmly to not use links to content on his site. Material such as his htaccess guide were at best misleading, as well the possibility of plagiarism. Sadly they do get very agressive when their material is modified or removed from the wiki, he has thus far refused to openly communicate with us, claiming ... we singled him out for abuse ... Megaspaz is a commited helper in #apache and I firmly believe he was doing his best to keep the wiki clean, and accurate. We have been lucky so far in that we have only had two spam posts, much less than was originally anticiapted. I find it very unfortunate that it has come to this, considering Rich and I struggled for quite some time to have the wiki created. When we first started using the wiki, the intention was for it to be a staging post for non docs comitters to submit works that can be then moved into the official docs project. It has now grown beyond my best expectations with lots of good content. As mentioned in a previous email to the docs list, this has now become the de facto FAQ, and is growing day on day. In fact we were highly praised by 3 or 4 individuals in #apache for the content, as it was accurate and helped them solve their issues with little fuss and with ease. This is testament to those of us who strive to make it so, and of the content in there. I have copies of these email conversations, and I am willing to forward them on to the appropriate people, rather than these lists as a whole. This gentleman has been a source of concern for sometime with some regulars in #apache. Reviewing some of his material leads us to conclude that he may have some very valuable input to the docs project, but the way in which he has handled the situation has been less than enthusiastic. Unfortunately there is no simple way, or for that matter a policy, of preventing him from accessing the wiki. He has already used 3 different user accounts to circumvent measures put in place. We could of course block his IP and delete hsi user account, but as we all know these are very easily circumvented anyway. On a policy: My opinion doesn't fit into a hard and fast rule, and rather relies upon discretion. -Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -Tony
Re: [Issue] External links @ the wiki, aka pagechange wars
Hi, On 5/24/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/23/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: We have a serious issue to determine, and I've asked for a 48 hour cooldown of wiki.apache.org/httpd/ to make a decision, and in the meantime asked that the wiki become read-only for the conclusion of this decision. [ X ] Our httpd wiki is open to external resources for httpd. [ ] External httpd resources are prohibited. snip / If a Wiki isn't open to community input ( where community here means *users*, not the typical Apache definition of community meaning the *committers*), then what is it for? Committers can already post to I Agree with Craig. Yoav
Re: [Issue] External links @ the wiki, aka pagechange wars
Yoav Shapira wrote: Hi, On 5/24/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/23/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: We have a serious issue to determine, and I've asked for a 48 hour cooldown of wiki.apache.org/httpd/ to make a decision, and in the meantime asked that the wiki become read-only for the conclusion of this decision. [ X ] Our httpd wiki is open to external resources for httpd. [ ] External httpd resources are prohibited. snip / If a Wiki isn't open to community input ( where community here means *users*, not the typical Apache definition of community meaning the *committers*), then what is it for? Committers can already post to I Agree with Craig. ditto. Derby has a Uses of Derby wiki page [1] and an articles/tutorials/tips page [2] that we encourage users to update. It's fine for somebody to post a link to his/her own article (they are the ones who are likely to know about it in the first place). but methinks we should add a disclaimer to each page that says the derby project doesn't verify/endorse the information or products provided at any of those links. -jean [1] http://wiki.apache.org/db-derby/UsesOfDerby [2] http://wiki.apache.org/db-derby/WorkingWithDerby Yoav
Re: [Issue] External links @ the wiki, aka pagechange wars
Joshua Slive wrote: On 5/24/07, Rich Bowen [EMAIL PROTECTED] wrote: On May 24, 2007, at 04:23, Tony Stevenson wrote: AskApache has had several email conversations with both myself, and Rich. In which he was asked politely, but firmly to not use links to content on his site. NOTE: NOT because external links are bad, but because the articles to which he was linking were misleading, incorrect, and promoted sub- optimal solutions to common problems. The implied endorsement (The Apache docs link to this article, so it must be true) was unfortunate, and undesirable. Although I respect Bill's desire to have this solved apache-wide, I actually think that this case would have been better addressed in the closer confines of [EMAIL PROTECTED] Let's just address this particular case and not worry about the general issue for now. The Apache wiki is not some democratic exercise like wikipedia where we need to treat everyone equally. We are a meritocracy, not a democracy, even on the wiki. Certain people (like Rich) have earned the right to make final decisions about what should be on the wiki. AskApache has not earned that right. The content that he is adding is inappropriate (and violates my suggested policy) for many reasons. I suggest that someone email him and tell him that he is henceforth banned from: 1) Making any links to his personal site; and 2) Reverting any change made by someone else (even if that change is a reversion of his change). If he can't live with those rules, he can be banned for good. +1 Would it be possible to re-enable write access for known 'good guys' so we can continue the process maintaining the wiki? If you would like me to send this email (as someone who has not interacted with him before) I'd be fine with that (although I don't know his address). Josh, I am happy to send this mail too, as I already have a history with him. I am not sure he will react overly well with someone else 'wading in' to this. Joshua. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -Tony
RE: [Issue] External links @ the wiki, aka pagechange wars
Hello, I've never used this list so bear with me, I couldn't get docs-help to send me help.Its nice to know Apache has so many helpful people willing to discuss this situation, but why do I get the feeling that none of you have actually read the page in question? Here is the link that is causing all the commotion: http://www.askapache.com/htaccess/apache-status-code-headers-errordocument.h tml I encourage you to read it and then you can understand my position. After you read the article, how could you possibly say that it is spam? That is perhaps the most relevant article I've ever seen about Apache ErrorDocuments and more specifically, HTTP Status Codes. Its the single, only place on the entire Internet where each of Apache's 57 Status Codes are listed. Its the only place on the Net where you can find the headers of each Apache ErrorDocument. Its the only article anywhere to have every single returned errordocument. I know because I did the work, I filled in the blanks on the Common_HTTPStatusCodes, I wrote it, and I published my findings to support open-source and Apache, and for the benefit of the entire net community. I actually did research on the external linking of sources or references on the Apache wiki, asf, many other apache wikis, and the link to my article is 100% compliant with the policies, but besides that it is a really fantastic article with 100% relevancy. 1. There is no copyright issue. 2. Its 100% relevant to the wiki article. 3. Its the ONLY place on the NET with that information. It is the authoritative link because its the original source. 4. Its a not-for-profit site. 5. The source that I used to fill in the many blanks on the Status Code table was my article, and since the article is incredibly lengthy a link to the original source is 100% warranted. 6. AskApache.com is registered for another 7 years, so these links are stable. 7. Have you even read the article? I once again find myself in a wiki battle of reverts, but I just don't have the patience or the time to be harassed every time I contribute to the wiki. Its supposed to be a place where new ideas and drafts can flourish, shutting people down who want to contribute is not cool. Calling me a spammer and calling my policy-compliant link spam is disingenuous and that rudeness and immaturity is NOT following the guidelines and policies of apache and asf. I have probably spent over 30 hours trying to contribute to the wiki, which I understood to be the trial area for working out new documentation. A work-in-progress where the point was shared collaboration. Unfortunately pctony and megaspaz have refused to let me post anything on the wiki.. It seems that every tip and suggestion I contribute immediately gets shot down as either being plagiarised, misleading and incorrect, or they just don't give me an excuse. I have literally spent hours writing a new wiki article in the ScratchPad area, and a few minutes after I posted it was immediately deleted. My stuff isn't discussed or improved upon or checked out, its just completely deleted. My email address is on my username page on the wiki, and I have emailed both pctony and megaspaz several times to try and get them to understand we are on the same team and the wiki isn't their personal feifdom. Look at my site, askapache.com. Its almost entirely dedicated to Apache httpd tips, tricks, etc.. I challenge pctony and megaspaz to stop deleting all my posts and instead show me how its wrong. Anyone who knows anything about Apache will immediately recognize my posts for being original, creative, and incredible resources for the whole web to enjoy for free. My billing is currently $125/hr, I am NOT trying to make any kind of profit from askapache.com, and to suggest my articles are spam is complete ludicrous. Anyone can shout slogans, I put the code up on the NET for everyone to discuss and improve. We are all like-minded here when it comes to Apache, so I hope we can rise above the emotional aspects of this issue and instead focus on making the wiki a more productive and friendly place for everyone who has ideas and is willing to donate their time and effort. -AskApache No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.7/816 - Release Date: 5/23/2007 3:59 PM
RE: [Issue] External links @ the wiki, aka pagechange wars
The trouble in this particular case is that the contributor in question writes articles that are misleading or completely wrong, and appears to be unaware of the fact that he is being misleading and wrong. I'm not sure if he's genuinely trying to be helpful, or merely trying to inflate his google ranking by creating pages that link back to his site. If I am misleading or wrong in any way shape or form than it is absolutely accidental. Instead of repeatedly telling me how bad my contributions are, and deleting anything I try to contribute, why not just point out WHERE I am wrong, WHERE I am misleading, that way we can work together and add valuable content to the wiki. Not to mention I can revise the articles on my blog, which means your feedback will be helping thousands of newbie Apache users. Either way, the content that he produces does not add substantial value, nor do the pages to which he links, and often his content actively promotes practices that are discouraged as being less-than-best-practice. I don't care if you are the top Apache Guru on the planet, the fact is that thousands of people DO think that my articles add substantial value, and if you really feel my stuff is that bad its your problem, not the content. Otherwise I would encourage you to make suggestions, point out errors, highlight alternatives, illustrate best-practices, instead of just talking about how bad my contributions are. Added to this is his refusal to accept correction, so that when his articles are modified to reflect best practice and reality, he gets offended and changes it back. Say whatever you want, I'm not going to argue when the evidence is online for everyone to examine. Go look at the wiki at my posting history, you will see how unfairly I have been treated. Behind the scenes there are angry and insulting email messages being exchanged, which I'm occasionally copied on, in which he defends his articles as being the best things ever written, and accusing us of singling him out for abuse. It's all very juvenile and time consuming. I believe I've written 3 people a total of 5 emails in the past 4 months. I saved everything so I don't have to argue or use sweeping generalizations, facts speak for themselves. I just don't understand all the unfriendliness and pettiness from 2 individuals since day 1 (look at my wiki history). In fact, one of the people actually went to my blog and left this kindhearted public comment. This is the most idiotic ‘tip’ I’ve ever read on the web since 1990 I am curious as to how you manage to generate technological content, you must be copying and pasting from different sources. Pleasant no? I feel like just because I posted some radical, new, and alternative ideas and solutions that might not have been discussed elsewhere before, people get a little competitive and want me to fall in line or something. I can already here the response: your stuff wasn't new or radical, it didn't solve anything, it was wrong, poorly written, and definately misleading. Why not respond like you are supposed to and actually SHOW me what is wrong, misleading, or poorly written? Isn't that what the wiki is for? How can we improve content when it just gets deleted right away? I don't have time to try to make a couple people like me.. thats silly, I go to the wiki to contribute, share ideas, and learn about my favorite software. I am only interested in being able to help and contribute to the wiki without immediately being deleted, reverted, and publically dissed both personally and academically. I understand how it could have gotten to this point, drama is always exciting, but the past is the past and I am just wanting to contribute. I've been trying for several months now, with month long breaks in-between, but I feel like if the people with grudges can't let it go, then I will never be able to contribute. Isn't there a policy or a guideline or someone with rank that can point the way to put this behind us? Teamwork makes the Dream Work No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.7/816 - Release Date: 5/23/2007 3:59 PM
[RELEASE CANDIDATE] libapreq 1.34-RC3
The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Additionally, the memory allocation algorithm for multipart requests has been improved. Please give the tarball at http://people.apache.org/~issac/libapreq-1.34-RC3.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] Thanks, Issac
Re: [Fwd: Apache httpd vulenrabilities]
On May 29, 2007, at 5:28 PM, William A. Rowe, Jr. wrote: Essentially, PID tables need to move from the score to a local process list only in the parent, and unshared. That would solve the 80/20 of this entire class of issues. Yes... Of course, it doesn't even need to be that extensive. If the parent process simply keeps in local storage a list of PIDs and before it does anything to the child process (send signal), it checks that the PID in the scoreboard is also in its own list, and only continues if it is This means that the scoreboard stays as is and the parent process just needs a small list of pid's added to it, plus some minor logic. The next coupla days I'll be mostly offline since my oldest son Jon is graduating and so there's the graduation, and planning, and party, etc...
Re: Apache2 mod_ssl with HSM support
Marc Stern wrote: That would definitely be a good thing. More and more servers are using a HSM, and we only can suggest to our customers who want to do so to use a commercial server like IIS. Marc mod_nss uses NSS as the crypto library instead of OpenSSL and supports PKCS#11 drivers out-of-the-box. Once the module is loaded hardware tokens are treated just like software tokens, you just may have to address them slightly differently (token:nickname). Works with Apache 2.0.x and 2.2.x. http://directory.fedoraproject.org/wiki/Mod_nss rob smime.p7s Description: S/MIME Cryptographic Signature
Re: httpd 1.3 / 2.0 / 2.2 tags this weekend?
On May 30, 2007, at 1:56 AM, William A. Rowe, Jr. wrote: I'd like to see new tarballs rolled soonish, given the single significant bug that was disclosed earlier today. Obviously most mass-vhosters are capable of compiling their own binary, so providing the seperate-pid-table patch (whoever gets around to writing one) resolves any immediate urgency. But people get skittish when they see httpd anywhere near vulnerability, so I'll roll apr 0.9/1.2 in 36 hours which means midday Sunday it's likely to be released and ready to drop into 2.0 / 2.2. 1.3 could be rolled/released whenever it's been patched, but I'd personally rather see *one* announcement, again, like we did about a year back, so we don't have silly people scrambling to install 1.3 in place of 2.2 :) I volunteer to roll 1.3 when it's ready, since Sander offered to roll 2.2 (and perhaps 2.0?) Sounds good. I can likely take a look at adding the parent has local pid table and verifies scoreboard with it patch to 1.3 maybe over the weekend (the 2.0 and 2.2 will likely follow the same concept), unless someone beats me to it :)
Re: httpd 1.3 / 2.0 / 2.2 tags this weekend?
On May 29, 2007, at 10:56 PM, William A. Rowe, Jr. wrote: I volunteer to roll 1.3 when it's ready, since Sander offered to roll 2.2 (and perhaps 2.0?) I'll be happy to RM both. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: [Fwd: Apache httpd vulenrabilities]
On 05/30/2007 08:10 PM, Jim Jagielski wrote: On May 29, 2007, at 5:28 PM, William A. Rowe, Jr. wrote: Essentially, PID tables need to move from the score to a local process list only in the parent, and unshared. That would solve the 80/20 of this entire class of issues. Yes... Of course, it doesn't even need to be that extensive. If the parent process simply keeps in local storage a list of PIDs and before it does anything to the child process (send signal), it checks that the PID in the scoreboard is also in its own list, and only continues if it is This means that the scoreboard stays as is and the parent process just needs a small list of pid's added to it, plus some minor logic. This is also my thought on this. Maybe the logic could be extended somewhat so that the parent cross checks / sanity checks the number of pids in its local storage and the number of active pids (a.k.a non empty slots) in whatever state they are every time it decides that it needs to start additional childs / kill childs. This should avoid / reduce issues #1 / #4. The next coupla days I'll be mostly offline since my oldest son Jon is graduating and so there's the graduation, and planning, and party, etc... All the best to Jon. Regards Rüdiger
Re: httpd 1.3 / 2.0 / 2.2 tags this weekend?
On Wed, 30 May 2007 11:31:02 +0200 Ruediger Pluem [EMAIL PROTECTED] wrote: Given the fact that we wanted to do this about 4 weeks ago anyway +1 on rolling. But we should wait for a seperate-pid-table patch, because releasing now with the security statement out and no patch for at least the one that we regard as somewhat sensitive seems to have the potential of confusing people even more than not releasing. (They release a new version without a fix for this security hole. WTF?). +1 to that. We can't entirely ignore the wagging of tongues. We also have remaining bugfixes that *should* go in. PR#39710 is simple enough to review, and another release without fixing that would be a huge WTF??? I'm also part way through reviewing Chris's mod_dbd rewrite. It's clearly an improvement on what we have, but getting three +1s by the weekend seems optimistic. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: [Fwd: Apache httpd vulenrabilities]
On May 30, 2007, at 2:57 PM, Ruediger Pluem wrote: On 05/30/2007 08:10 PM, Jim Jagielski wrote: On May 29, 2007, at 5:28 PM, William A. Rowe, Jr. wrote: Essentially, PID tables need to move from the score to a local process list only in the parent, and unshared. That would solve the 80/20 of this entire class of issues. Yes... Of course, it doesn't even need to be that extensive. If the parent process simply keeps in local storage a list of PIDs and before it does anything to the child process (send signal), it checks that the PID in the scoreboard is also in its own list, and only continues if it is This means that the scoreboard stays as is and the parent process just needs a small list of pid's added to it, plus some minor logic. This is also my thought on this. Maybe the logic could be extended somewhat so that the parent cross checks / sanity checks the number of pids in its local storage and the number of active pids (a.k.a non empty slots) in whatever state they are every time it decides that it needs to start additional childs / kill childs. This should avoid / reduce issues #1 / #4. :) My thoughts exactly... The only issue with pulling parent out of scoreboard is, of course, the backwards compatibility with modules that may be interested in it...
Re: httpd 1.3 / 2.0 / 2.2 tags this weekend?
On May 30, 2007, at 2:41 PM, Sander Temme wrote: On May 29, 2007, at 10:56 PM, William A. Rowe, Jr. wrote: I volunteer to roll 1.3 when it's ready, since Sander offered to roll 2.2 (and perhaps 2.0?) I'll be happy to RM both. I'd like to, but my time will be sporadic enough the next few days as to make it unwise to depend on me to do this :)
Re: [Issue] External links @ the wiki, aka pagechange wars
On Thu, 24 May 2007 15:15:56 -0500 Webmaster [EMAIL PROTECTED] wrote: Hello, I've never used this list so bear with me, I couldn't get docs-help to send me help.Its nice to know Apache has so many helpful people willing to discuss this situation, but why do I get the feeling that none of you have actually read the page in question? Here is the link that is causing all the commotion: http://www.askapache.com/htaccess/apache-status-code-headers-errordocument.h tml I encourage you to read it and then you can understand my position. OK, I just looked. And to be brutal ... WTF The first error is to call them Apache Status Codes. That's a nasty one to perpetrate on innocent newbies, because it obscures what they really are, and misleads the reader. First sentence: There are a total of 57 HTTP Status Codes recognized by the Apache Web Server. Sorry, that's plain nonsense - though at least it describes them correctly. The article then suggests using any or all of them with Apache's Redirect. It does so without any attempt to explain the meaning of any of the status codes, so it cannot be said to add anything to Apache's default behaviour or the mod_alias documentation. Rather it confuses the issue for readers who don't have sufficient grasp of HTTP to see that it's gibberish. The fact that Apache enables you to shoot yourself in the foot is not a good reason to do so. It then proceeds to list HTTP status codes, and gives an errordocument for each one. Unfortunately a number of them are bogus gibberish. After you read the article, how could you possibly say that it is spam? That is perhaps the most relevant article I've ever seen about Apache ErrorDocuments and more specifically, HTTP Status Codes. Spam is not the right word. But it's far too ill-informed and misleading to give the implied endorsement of a link from an official or semi-official Apache site. I'm sure you could make a useful contribution if you want to. But you're not ready to go solo. So why not put your contents (rather than links to it) on the wiki, where some of the regulars can help improve it for everyone? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: [Issue] External links @ the wiki, aka pagechange wars
ons 2007-05-30 klockan 21:39 +0100 skrev Nick Kew: It then proceeds to list HTTP status codes, and gives an errordocument for each one. Unfortunately a number of them are bogus gibberish. It's the gibberish Apache emits if you shoot yourself in the foot using Redirect. Garbage in, garbage out. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [Fwd: Apache httpd vulenrabilities]
On 05/30/2007 09:45 PM, Jim Jagielski wrote: On May 30, 2007, at 2:57 PM, Ruediger Pluem wrote: On 05/30/2007 08:10 PM, Jim Jagielski wrote: On May 29, 2007, at 5:28 PM, William A. Rowe, Jr. wrote: Essentially, PID tables need to move from the score to a local process list only in the parent, and unshared. That would solve the 80/20 of this entire class of issues. Yes... Of course, it doesn't even need to be that extensive. If the parent process simply keeps in local storage a list of PIDs and before it does anything to the child process (send signal), it checks that the PID in the scoreboard is also in its own list, and only continues if it is This means that the scoreboard stays as is and the parent process just needs a small list of pid's added to it, plus some minor logic. This is also my thought on this. Maybe the logic could be extended somewhat so that the parent cross checks / sanity checks the number of pids in its local storage and the number of active pids (a.k.a non empty slots) in whatever state they are every time it decides that it needs to start additional childs / kill childs. This should avoid / reduce issues #1 / #4. :) My thoughts exactly... The only issue with pulling parent out of scoreboard is, of course, the backwards compatibility with modules that may be interested in it... Sorry for being confused now. I thought the idea was to have an additional local pid list in the parent for cross / sanity checking. The scoreboard remains as it is (including the pids). So what could modules possible miss after the patch? Regards Rüdiger
Re: httpd 1.3 / 2.0 / 2.2 tags this weekend?
On 05/30/2007 09:37 PM, Nick Kew wrote: We also have remaining bugfixes that *should* go in. PR#39710 is simple enough to review, and another release without Good reminder. I just casted my vote for the backport. So lets hope that we get the missing +1. fixing that would be a huge WTF??? I'm also part way through reviewing Chris's mod_dbd rewrite. It's clearly an improvement on what we have, but getting three +1s by the weekend seems optimistic. Yes, that would be very optimistic. IMHO his patches deserve more attention, but I am currently too short on time and not so familar with the mod_dbd code that I can do this. But as there are several proposals from Chris, you and Chris may be able to advice which of them are most important / easiest to review. So maybe some lower hanging fruits :-). Regards Rüdiger
Re: [Fwd: Apache httpd vulenrabilities]
Ruediger Pluem wrote: On 05/30/2007 09:45 PM, Jim Jagielski wrote: On May 30, 2007, at 2:57 PM, Ruediger Pluem wrote: On 05/30/2007 08:10 PM, Jim Jagielski wrote: On May 29, 2007, at 5:28 PM, William A. Rowe, Jr. wrote: Essentially, PID tables need to move from the score to a local process list only in the parent, and unshared. That would solve the 80/20 of this entire class of issues. Yes... Of course, it doesn't even need to be that extensive. If the parent process simply keeps in local storage a list of PIDs and before it does anything to the child process (send signal), it checks that the PID in the scoreboard is also in its own list, and only continues if it is This means that the scoreboard stays as is and the parent process just needs a small list of pid's added to it, plus some minor logic. This is also my thought on this. Maybe the logic could be extended somewhat so that the parent cross checks / sanity checks the number of pids in its local storage and the number of active pids (a.k.a non empty slots) in whatever state they are every time it decides that it needs to start additional childs / kill childs. This should avoid / reduce issues #1 / #4. :) My thoughts exactly... The only issue with pulling parent out of scoreboard is, of course, the backwards compatibility with modules that may be interested in it... Sorry for being confused now. I thought the idea was to have an additional local pid list in the parent for cross / sanity checking. The scoreboard remains as it is (including the pids). So what could modules possible miss after the patch? Not sure where the confusion is... the idea is to keep the scoreboard exactly as-is (as noted above, pulling out the parent parts (pid), would be a major issue for backwards compatibility), and just add pid-checking logic (and a local store of pids) in the parent process. Thus, it's completely transparent and no changes to the scoreboard or any entities that use it (except for the mentioned parent-side checking, 'natch) :) The only issue... refers to the problems if we try to restructure the scoreboard instead, which is good for 2.4/3.0 but not for 2.2, 2.0 and 1.3... Any patches that tried to address the issue using that method would be problematic. Hence my thoughts to just have local storage for checking and keeping scoreboard as-is. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [Fwd: Apache httpd vulenrabilities]
On May 30, 2007, at 3:09 PM, Jim Jagielski wrote: Hence my thoughts to just have local storage for checking and keeping scoreboard as-is. +1 on this approach. S. -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: [Fwd: Apache httpd vulenrabilities]
On 05/31/2007 12:09 AM, Jim Jagielski wrote: The only issue... refers to the problems if we try to restructure the scoreboard instead, which is good for 2.4/3.0 but not for 2.2, 2.0 and 1.3... Any patches that tried to address the issue using that method would be problematic. Hence my thoughts to just have local storage for checking and keeping scoreboard as-is. Ahh. Got it. Completely agree. Thanks for the clarification. Regards Rüdiger
[STATUS] (httpd-2.2) Wed May 30 23:49:19 2007
APACHE 2.2 STATUS: -*-text-*-
Last modified at [$Date: 2007-05-30 17:05:31 -0400 (Wed, 30 May 2007) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
Documentation status is maintained seperately and can be found at:
* docs/STATUS in this source tree, or
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS
Consult the following STATUS files for information on related projects:
* http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
* http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS
Patches considered for backport are noted in their branches' STATUS:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
Release history:
[NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
while x.{even}.z versions are Stable/GA releases.]
2.2.5 : In Development
2.2.4 : Released on January 9, 2007 as GA.
2.2.3 : Released on July 28, 2006 as GA.
2.2.2 : Released on May 1, 2006 as GA.
2.2.1 : Tagged on April 1, 2006, not released.
2.2.0 : Released on December 1, 2005 as GA.
2.1.10 : Tagged on November 19, 2005, not released.
2.1.9 : Released on November 5, 2005 as beta.
2.1.8 : Released on October 1, 2005 as beta.
2.1.7 : Released on September 12, 2005 as beta.
2.1.6 : Released on June 27, 2005 as alpha.
2.1.5 : Tagged on June 17, 2005.
2.1.4 : not released.
2.1.3 : Released on February 22, 2005 as alpha.
2.1.2 : Released on December 8, 2004 as alpha.
2.1.1 : Released on November 19, 2004 as alpha.
2.1.0 : not released.
Contributors looking for a mission:
* Just do an egrep on TODO or XXX in the source.
* Review the bug database at: http://issues.apache.org/bugzilla/
* Review the PatchAvailable bugs in the bug database:
https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2keywords=PatchAvailable
After testing, you can append a comment saying Reviewed and tested.
* Open bugs in the bug database.
CURRENT RELEASE NOTES:
* Forward binary compatibility is expected of Apache 2.2.x releases, such
that no MMN major number changes will occur. Such changes can only be
made in the trunk.
* All commits to branches/2.2.x must be reflected in SVN trunk,
as well, if they apply. Logical progression is commit to trunk,
get feedback and votes on list or in STATUS, then merge into
branches/2.2.x, as applicable.
RELEASE SHOWSTOPPERS:
PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
PATCHES PROPOSED TO BACKPORT FROM TRUNK:
* ApacheMonitor: Fix Windows Vista detection.
http://svn.apache.org/viewvc?view=revrevision=536052
+1: mturk
wrowe notes post today to list, can we please test for = VISTA
so this doesn't break again upon the release of longhorn server
or 'nextgen' windows?
* mpm_winnt: Fix return values from wait_for_many_objects.
Note - this is required to avoid hangups of socket #64, #128
as Microsoft set aside 64 reserved values.
Trunk version of patch:
http://svn.apache.org/viewvc?view=revrevision=428029
2.2.x version of patch:
Trunk version works
http://people.apache.org/~wrowe/mpm_winnt_waits.patch
is easier to read (-U8)
+1: mturk
+0: fielding (patch is okay, underlying code is crap)
wrowe notes: a patch should have the necessary effect with the
minimum lines of code - there's alot of redecorating that's
going on in this patch to no net effect. The WAIT_TIMEOUT
result value seems to be ignored in the revised code?
mturk notes: WAIT_TIMEOUT is replaced by WAIT_FAILED with
the accompanied patch in mpm\winnt\child.c.
fielding notes: the routine is brain-dead -- one cannot replicate
a wait for many objects by iterating through multiple waits with
a one second sleep in between loops. That's insane.
The right ways to do that are explained in the MSDN article
http://msdn2.microsoft.com/en-us/library/ms687025.aspx
In any case, it should be checking nCount = MAXIMUM_WAIT_OBJECTS
first and use the simple wait in that case.
* mod_authn_dbd: Export any additional columns queried in the SQL select
into the environment with the name AUTHENTICATE_COLUMN. This brings
mod_authn_dbd behaviour in line with mod_authnz_ldap.
Trunk: http://svn.apache.org/viewvc?view=revrevision=466865
+1: minfrin
niq: This wants a little tidying. Use of 13 as a magic number (for a
strlen of
[STATUS] (httpd-2.0) Wed May 30 23:48:47 2007
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2007-05-08 19:18:57 -0400 (Tue, 08 May 2007) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS Documentation status is maintained seperately and can be found at: * docs/STATUS in this source tree, or * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS Consult the following STATUS files for information on related projects: * http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x/STATUS * http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x/STATUS Consult the trunk/ for all new development and documentation efforts: * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS Release history: 2.0.60 : in maintenance 2.0.59 : released July 28, 2006 as GA. 2.0.58 : released May 1, 2006 as GA. 2.0.57 : tagged April 19, 2006, not released. 2.0.56 : tagged April 16, 2006, not released. 2.0.55 : released October 16, 2005 as GA. 2.0.54 : released April 17, 2005 as GA. 2.0.53 : released February 7, 2005 as GA. 2.0.52 : released September 28, 2004 as GA. 2.0.51 : released September 15, 2004 as GA. 2.0.50 : released June 30, 2004 as GA. 2.0.49 : released March 19, 2004 as GA. 2.0.48 : released October 29, 2003 as GA. 2.0.47 : released July 09, 2003 as GA. 2.0.46 : released May 28, 2003 as GA. 2.0.45 : released April 1, 2003 as GA. 2.0.44 : released January 20, 2003 as GA. 2.0.43 : released October 3, 2002 as GA. 2.0.42 : released September 24, 2002 as GA. 2.0.41 : rolled September 16, 2002. not released. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the bug database at: http://issues.apache.org/bugzilla/ * Review the PatchAvailable bugs in the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable After testing, you can append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: * Forward binary compatibility is expected of Apache 2.0.x releases, such that no MMN major number changes will occur. Such changes can only be made in the trunk. * All commits to branches/2.0.x must be reflected in SVN trunk, as well, if they apply. Logical progression is commit to trunk, get feedback and votes on list or in STATUS, then merge into branches/2.2.x, and finally merge into branches/2.0.x, as applicable. RELEASE SHOWSTOPPERS: PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] PATCHES PROPOSED TO BACKPORT FROM TRUNK: [ please place SVN revisions from trunk here, so it is easy to identify exactly what the proposed changes are! Add all new proposals to the end of this list. ] * ApacheMonitor: Fix Windows Vista detection. http://svn.apache.org/viewvc?view=revrevision=536052 +1: mturk *) Reverse Proxy fixes: Location bug and Cookie support Patch is at http://people.apache.org/~colm/httpd-2.0-reverse-proxy-cookie.patch and is in production with Clients. +1: niq, wrowe wrowe adds; looks
Compiling Apache 2.0.59 source on Windwos 64-bit
Dear All, We need to support our application using Apache 2.0.59(64-bit) on Win 2k3 SP1 (64-bit). We tried to look for 64-bit installable for Apache 2.0.59 on apache website, but failed to find one. Is Apache 2.0.59 supported on Win64? So we have downloaded the apache 2.0.59 source code for Windows(httpd-2.0.59-win32-src.zip). Will the source code compile on Windows 64-bit or there is a separate source for 64-bit apache. If same source can be used for both 32-bit 64-bit windows, are there any specific steps to build on Win64. Please guide us. Note: We were able to locate apache 2.2.3 installable for win64. We need same for apache 2.0.59. Thanks, Renu CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS***
