Re: network byte ordering in ContentDigest?
On Mon, Dec 21, 2009 at 2:20 PM, Deepak Nagaraj n.dee...@gmail.com wrote: Hi, The ContentDigest option does not seem to convert the MD5 to network byte order before doing base64 encoding. The RFC says: It's 16 bytes, what reordering did you want to do? Byte order only applies to stuff larger than individual bytes. Olaf
Re: network byte ordering in ContentDigest?
On Mon, Dec 21, 2009 at 3:07 PM, Deepak Nagaraj n.dee...@gmail.com wrote: It's 16 bytes, what reordering did you want to do? Byte order only applies to stuff larger than individual bytes. The RFC considers it as a 128-bit digest (=number). It can be divided into 16 bytes in either host order or network order. Because the RFC says when viewed in network order, it implies that we need to do host-to-network conversion. This is the conversion I'm referring to. AFAIK that really doesn't apply. It's not an int, it's a 16-byte 'array' that shouldn't be reordered. Olaf
Re: network byte ordering in ContentDigest?
On Mon, Dec 21, 2009 at 5:07 PM, Deepak Nagaraj n.dee...@gmail.com wrote: AFAIK that really doesn't apply. It's not an int, it's a 16-byte 'array' that shouldn't be reordered. You're right about MD5. I checked the MD5-algorithm RFC (1321). It specifies that the digest is generated in little-endian order. The message digest produced as output is A, B, C, D. That is, we begin with the low-order byte of A, and end with the high-order byte of D. So as long as the generator and verifier both follow the MD5 algorithm as per its RFC, we should be OK. But on the other hand, HTTP Content-MD5 header RFC (1864) explicitly mentions network byte ordering as I originally quoted. Being a standards-compliant HTTP server, IMO, we should be doing whatever the RFC says, even if it's a nuance. What RFC? The MD5 one? Or the HTTP MD5 one (1864)? Olaf
Re: network byte ordering in ContentDigest?
On Mon, Dec 21, 2009 at 6:35 PM, Deepak Nagaraj n.dee...@gmail.com wrote: On Mon, Dec 21, 2009 at 11:02 PM, Olaf van der Spek olafvds...@gmail.com wrote: But on the other hand, HTTP Content-MD5 header RFC (1864) explicitly mentions network byte ordering as I originally quoted. Being a standards-compliant HTTP server, IMO, we should be doing whatever the RFC says, even if it's a nuance. What RFC? The MD5 one? Or the HTTP MD5 one (1864)? The HTTP MD5 RFC (1864), since that's what Apache ContentDigest implements. So what exactly are you proposing? An example of actual bytes in de MD5 in BE and LE would help. Olaf
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
On Tue, Dec 1, 2009 at 9:03 PM, Gregg L. Smith li...@glewis.com wrote: And what is passing for an excuse for a local PCRE install these days probably doesn't look like 7.8 or later, with various fixes we are vulnerable to. Isn't that the responsibility of the distributor? This does not leave me with a warm and fuzzy feeling. As a user, is the pcre 8.0 I've built going to expose me to risks that your maintained 7.8 does not? If yes, then I'd prefer your maintained one. After all, who knows better than you what will interact with your code to produce problems. Regardless of merit, who will ultimately get blamed in the end? Could your reputation be tarnished? Can you completely divorce yourself from something your software requires to run? The opposite might be true too, what about risks that have been patched in the distribution but not in the one shipped by Apache? IMO library duplication should be avoided as much as possible. Olaf
Re: [mod_fcgid] Feedback / Suggestions
On Thu, Nov 26, 2009 at 9:26 AM, Edgar Frank ef-li...@email.de wrote: I'd much rather see effort put into mod_proxy_fcgi to support this use case. I wish somebody, perhaps myself, had time to work on it. It doesn't seem that hard a task. Just an idea, I though about - what would you think about pulling mod_proxy_fcgi up to the FCGI-code base of mod_fcgid? Could be kind of difficult, as mod_fcgid is maintained separately at the moment, but IMHO mod_fcgid has a much more sophisticated code in FCGI-communication (e.g. using own bucket types) and adhering to the CGI standard. If, in theory, both were sitting on the same code base, any fixes/changes/ enhancements in FCGI handling would affect and improve mod_proxy_fcgi, too. This way, mod_proxy_fcgi would be the superior choice for externally spawned workers (where dynamic worker selection really starts to make any sense) while mod_fcgid cares about local workers and process management - and every module would serve its very own purpose. Okay, this has some downsides, too, like increased testing overhead, but in general I like the idea. I would be glad to hear your thoughts. In an ideal situation you don't have two separate modules. So don't go that way. ;) Spawning is nice but IMO not that important and in an ideal case you might want to run the backend with a different user ID than the frontend. Olaf
Re: [mod_fcgid] Feedback / Suggestions
On Wed, Nov 25, 2009 at 11:37 AM, Edgar Frank ef-li...@email.de wrote: Maybe, in implementing this in mod_fcgid and making it configurable, Apache can serve more intelligent backends better. Wouldn't it be better to have the backend tell the frontend that it supports this feature? Manual configuration should be avoided if possible. Olaf
Re: [mod_fcgid] Feedback / Suggestions
On Wed, Nov 25, 2009 at 12:17 PM, Edgar Frank ef-li...@email.de wrote: Wouldn't it be better to have the backend tell the frontend that it supports this feature? Manual configuration should be avoided if possible. Yes, you're right. In a FCGI_GET_VALUES request, the backend can send arbitrary name-value-pairs. Unfortunately there is no standard way to tell the frontend that this feature is supported. Maybe, making the name (and expected value) of this name-value-pair configurable in mod_fcgid could be a reasonable way. Doesn't sound reasonable either. If you introduce such a feature, it should simply be coordinated with other FastCGI stakeholders. Olaf
Re: [mod_fcgid] Feedback / Suggestions
On Wed, Nov 25, 2009 at 12:54 PM, Edgar Frank ef-li...@email.de wrote: 2009/11/25 Olaf van der Spek olafvds...@gmail.com Yes, you're right. In a FCGI_GET_VALUES request, the backend can send arbitrary name-value-pairs. Unfortunately there is no standard way to tell the frontend that this feature is supported. Maybe, making the name (and expected value) of this name-value-pair configurable in mod_fcgid could be a reasonable way. Doesn't sound reasonable either. If you introduce such a feature, it should simply be coordinated with other FastCGI stakeholders. You're right, again. I'm just wondering if such a change is likely to happen. Last update was 2002. I'd like to propose a change to the FastCGI stakeholders, if this makes any sense from a single, unrelated person. The official spec is unlikely to change, so you'd have to coordinate with other web server and backend developers. Olaf
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 4:24 PM, Jeff Trawick traw...@gmail.com wrote: (1) mod_fcgid should be capable of specifying an external FCGI server. (2) In conjunction with (1), mod_fcgid should be able to select the backend server based on request data. I'd much rather see effort put into mod_proxy_fcgi to support this use case. I wish somebody, perhaps myself, had time to work on it. It doesn't seem that hard a task. What was the reason to import mod_fcgi again? Wasn't the ETA of mod_proxy_fcgi too high? In the interim, is mod_fastcgi really that bad? I assume mod_fcgi wasn't developed without proper reason. Olaf
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 4:47 PM, Jeff Trawick traw...@gmail.com wrote: What was the reason to import mod_fcgi again? Wasn't the ETA of mod_proxy_fcgi too high? mod_fcgid was imported because it was * widely used * not actively maintained * httpd developers were willing to adopt it I felt that it was a nice addition particularly because it had a different approach to this important problem space compared with mod_proxy_fcgi. What advantages does fcgid have over proxy_fcgi (except being ready)? In the interim, is mod_fastcgi really that bad? I assume mod_fcgi wasn't developed without proper reason. So do I. (FWIW, I've put a lot of time into mod_fcgid and expect to continue doing so in the future.) The situation at hand seems to be * mod_proxy_fcgi promises to meet those requirements but falls short at present * mod_fcgid doesn't even try * mod_fastcgi implements at least some of those requirements and is mature mod_fcgid isn't in 2.2, right? So what's the plan for 2.4? Have both of them? Or is mod_proxy_fcgi expected to be not ready for 2.4? Olaf
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 4:50 PM, pqf p...@mailtech.cn wrote: In this case, one httpd thread(process) will have to bind to one FastCGI process. I don't think connect() to a local pipe/unix domain socket is the bottle-neck, so let it be? Doesn't it require an extra round trip? It's probably not too bad, but would be nice to avoid. Olaf
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 5:03 PM, Jeff Trawick traw...@gmail.com wrote: What advantages does fcgid have over proxy_fcgi (except being ready)? integrated, on-demand process management How valuable is that? In most cases a static number of backends seems fine. mod_fcgid isn't in 2.2, right? mod_fcgid is actually not bundled with the HTTP server. It is released on its own cycle, and supports httpd 2.0.x, 2.2.x, and trunk (future httpd 2.4.x) with one delivery. Ah, nice. What's the reason it's not bundled though? In this case, I'd love to see support for TCP/IP backends too. Shouldn't be too hard to implement. So what's the plan for 2.4? Have both of them? Or is mod_proxy_fcgi expected to be not ready for 2.4? mod_fcgid will support 2.4. proxy-fcgi folk(s), care to speak up on your baby? Olaf
Re: Is async the answer?
On Jan 25, 2008 6:18 PM, Akins, Brian [EMAIL PROTECTED] wrote: On 1/24/08 3:14 PM, Olaf van der Spek [EMAIL PROTECTED] wrote: Working on making a FastCGI based setup the recommended approach instead of mod_php is probably more important then async. Actually, it's a prerequisite. Fastcgi is the recommended way of using php and httpd 2, AFAIK. Isn't it??? Where can I read about that recommendation? I can't find it in the Apache or PHP manuals. mod_php appears to be *the* solution. What about a hybrid approach? Async for network IO and other stuff that doesn't require sync calls, worker threads for other parts? That's kind of what I was thinking after Apachecon US this year. I won't speak for others, but it seemed reasonable to most. However, after doing several real world tests, I just don't honestly see that async will be a huge improvement. Please prove me wrong with real world results. I'd be more than happy to be wrong on this, really. I don't have real world test results. Have you tested the 30k scenario with an async web server? And do all platforms have such cheap threading as your test platform? To be honest, I don't have strong feelings either way. I was surprised by my results. I, now, think that completely rewriting the core to be async *may be* a waste of resources. If it fits nicely into some ideas on reengineering buckets and brigades (ala serf stuff), and does not actually decrease overall performance, then by all means do it. Remember, I'm partially playing devil's advocate as well... I noticed. ;)
Re: Is async the answer?
On Jan 28, 2008 8:04 PM, Eric Covener [EMAIL PROTECTED] wrote: On Jan 28, 2008 12:36 PM, Olaf van der Spek [EMAIL PROTECTED] wrote: On Jan 25, 2008 6:18 PM, Akins, Brian [EMAIL PROTECTED] wrote: On 1/24/08 3:14 PM, Olaf van der Spek [EMAIL PROTECTED] wrote: Working on making a FastCGI based setup the recommended approach instead of mod_php is probably more important then async. Actually, it's a prerequisite. Fastcgi is the recommended way of using php and httpd 2, AFAIK. Isn't it??? Where can I read about that recommendation? I can't find it in the Apache or PHP manuals. mod_php appears to be *the* solution. http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2 If you feel you have to use a threaded MPM, look at a FastCGI configuration where PHP is running in its own memory space. Is that what is meant by Fastcgi is the recommended way of using php and httpd 2, AFAIK. Isn't it A single line seems a bit odd for the recommended approach.
Re: Is async the answer?
On Jan 28, 2008 9:22 PM, Jim Jagielski [EMAIL PROTECTED] wrote: http://www.php.net/manual/en/ faq.installation.php#faq.installation.apache2 If you feel you have to use a threaded MPM, look at a FastCGI configuration where PHP is running in its own memory space. Is that what is meant by Fastcgi is the recommended way of using php and httpd 2, AFAIK. Isn't it A single line seems a bit odd for the recommended approach. Consider that, for many people, the main advantage of Apache2 over Apache1 is the worker MPM. Also consider that a threaded MPM and mod_php aren't a happy couple. If using prefork, mod_php works just dandy... but for other reasons you'd likely want to consider FastCGI anyway... I agree that FastCGI is the better technical solution, I'm just stating that neither the Apache documentation nor the PHP documentation seems to state that. Even worse, they hardly document the FastCGI way at all.
Re: Is async the answer?
On Jan 28, 2008 9:57 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Olaf van der Spek wrote: I agree that FastCGI is the better technical solution, I'm just stating that neither the Apache documentation nor the PHP documentation seems to state that. Even worse, they hardly document the FastCGI way at all. FastCGI is a technically subpar way to execute trusted, valid PHP. Why? Isn't memory (and other resource) consumption a lot lower because you don't need a PHP 'engine' for every thread/process? Even valid PHP code can crash, given bugs in PHP itself. And I think tons of users sometimes run untrusted or invalid PHP. People have always been under some preconception that it's good to run untrusted code in-process within httpd, while numerous vulnerability reports in the past (and many to appear over the future) all bear out that it's a really stupid idea. Given that the alternatives (FastCGI) isn't well documented, I don't think that's strange. FastCGI is also a so-so way to get around libraries which aren't thread- safe, running worker or event mpm's. Of course, using the 21st century equivalents of those libraries probably isn't a bad solution either. Olaf
Re: Is async the answer?
We were using normal worker MPM with keepalives for this test. The current stable event would have helped with idle keepalive threads, but the system didn't seem to care. But when using mod_php, worker is not recommended, right? I doubt prefork scales as well as worker. Working on making a FastCGI based setup the recommended approach instead of mod_php is probably more important then async. Actually, it's a prerequisite. Having 30k threads still seems like a waste of resource to me though. What about a hybrid approach? Async for network IO and other stuff that doesn't require sync calls, worker threads for other parts? Olaf
Re: Large file support in 2.0.56?
On 4/16/06, Joost de Heer [EMAIL PROTECTED] wrote: Colm MacCarthaigh wrote: On Sun, Apr 16, 2006 at 10:28:10PM +0200, Joost de Heer wrote: hmmm...that doesn't help me much. I'm more interested in large files in mod_dav. Right now I can't upload anything much bigger than 700MB. IMO, that's not something a webserver should be used for anyway. I do it all of the time. We have users who upload DVD iso's to their DAV shares. Can't see any reason why DAV shouldn't be capable of such things. There's a difference between 'being capable of' and 'being the proper tool for'. Of course, but why wouldn't DAV be the proper tool for it?
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
On 12/4/05, Ian Holsman [EMAIL PROTECTED] wrote: Garrett Rooney wrote: On 12/3/05, Ian Holsman [EMAIL PROTECTED] wrote: I'd also like to brainstorm a better solution to running Rails/Django applications inside of the httpd process than the SCGI/FastCGI solution which most people use. Out of curiosity, what do you think is wrong with the current FastCGI method of running them? configuration. for example in order for me to get typo running on my blog, I need 4 rewrite rules. (and when I tried to do something slightly different, it took me a good hour to configure it properly with all the rewrite magic) Wouldn't it be better to fix/improve the configuration? Why should/would an 'in-process' request processor be easier to configure than an out-of-process one? Not all things can run inside httpd and for PHP I think it'd also be nice if it ran outside. also when applications 'experts' like scott (the creator of typo) have issues like http://scottstuff.net/blog/articles/2005/07/20/apache-tuning-for-rails-and-fastcgi i think it isn't easy enough to run. what I am after is something as simple as RailsApp /foo/ rails-controller.rb [cache] [ENV=production] which would just work as a in-process application... making it as simple as running a PHP application is the goal. I don't like the trend i see with rails django people saying apache is hard to use and switching to other web servers.
Re: Directions for Win32 binary httpd
On 12/3/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: It seems that most of the communites are still in VC 6. Remember the key reason we keep using it, MS dropped support for exporting makefiles. With no makefiles, you are roped into supporting only version x or newer Studio products. With .dsp/.dsw solutions, we can export makefiles on the old reliable VC 6, and users can load/convert these into Studio 2000/03/05. So why not distribute the VC6 dsp/dsw files but (officially) build with VS05 yourself?
Re: OT: performance FUD
On 11/30/05, Colm MacCarthaigh [EMAIL PROTECTED] wrote: On Wed, Nov 30, 2005 at 11:01:55AM -0500, Paul A Houle wrote: So if one uses worker and few processes (i.e. lots of threads per), then Solaris should be fine? That's what people think, but I'd like to see some numbers. I've never put a worker Apache into production because most of our systems depend on PHP or something else which I wouldn't trust 100% in a threaded configuration. Is there anything we can do in 2.4/3.0 that will help gain that trust? I recently started a thread with (IMO) a potential solution: Any 'official' Apache FastCGI-like alternative planned? Even if PHP is thread-safe it's still not safe. One (bad) script can kill the entire server. The solution would be to run PHP (and other 'request processors') in a separate process.
Re: [vote] 2.2.0 tarballs
On 11/30/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Colm MacCarthaigh wrote: On Wed, Nov 30, 2005 at 02:43:24PM -0600, William A. Rowe, Jr. wrote: It was hardly nobody, I may be shoddily inexperienced with the win32 port, but I did go to the trouble of testing apr-iconv on win32 and have been regularly building 2.1/2.2 on win32 to make sure it builds/works for me. And we've heard from others doing the same. It was close to nobody, the only reason it is released is that yourself, and Garrett both stepped up. But I posted far more pings than I received in testers, and it took two months :) Thank you two for the review, no slight intended. Wouldn't it help if (beta) binaries are posted to http://httpd.apache.org/download.cgi?
Re: [vote] 2.2.0 tarballs
On 11/29/05, Paul Querna [EMAIL PROTECTED] wrote: Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Okay, I lied, slightly: Shouldn't the final always be equal except version number to the last rc?
Re: [vote] 2.2.0 tarballs
On 11/29/05, Justin Erenkrantz [EMAIL PROTECTED] wrote: On Tue, Nov 29, 2005 at 10:28:43AM -0500, Jim Jagielski wrote: I would agree, as long as we remove it for the What's New pages until it actually works and builds. My point, obviously, was that we can't have it both ways and say mod_dbd is great and a new core enhancement if it doesn't even build under Win32. Win32 is one platform among many that we support. Additionally, we have very few developers who care to maintain Win32. mod_dbd apparently works just fine on every other platform. Therefore, I don't think removing it from the feature list is warranted. If no one cared about it until now, I don't care about it either. If mod_dbd didn't work on Darwin, I wouldn't ask that we remove it from the features list if it works on Linux, Solaris, and Win32. I'd ask that it be noted and move along. I don't know why we would or should grant special consideration to Win32 here. -- justin Why not add a special 'except on Windows' clause to that page?
Any 'official' Apache FastCGI-like alternative planned?
Hi, I've been wondering, do the Apache developers plan to develop and/or include an official FastCGI-like module in Apache? I know there's for example AJP but that appears to be aimed specifically at Java. An official module would be handy so that PHP can be run in separate processes without requiring the http server itself to use separate processes.
Re: Any 'official' Apache FastCGI-like alternative planned?
On 11/27/05, Joshua Slive [EMAIL PROTECTED] wrote: Olaf van der Spek wrote: Hi, I've been wondering, do the Apache developers plan to develop and/or include an official FastCGI-like module in Apache? I know there's for example AJP but that appears to be aimed specifically at Java. An official module would be handy so that PHP can be run in separate processes without requiring the http server itself to use separate processes. You might be interested to read http://httpd.apache.org/docs/1.3/misc/FAQ.html#fastcgi I don't think the logic in that answer is set in stone. But that is the history of it. With the latest update at http://www.fastcgi.com/dist/ being November 2003 I doubt that would still be an issue.
Re: Any 'official' Apache FastCGI-like alternative planned?
On 11/27/05, Nick Kew [EMAIL PROTECTED] wrote: On Sunday 27 November 2005 22:11, Olaf van der Spek wrote: Hi, I've been wondering, do the Apache developers plan to develop and/or include an official FastCGI-like module in Apache? Nope. There's the old mod_fastcgi and the more up-to-date mod_fcgid out there. Why does the world need another? But not in the official Apache distribution. And not with a Debian/DFSG-free license. If you have a specific need that the above don't meet, perhaps FastCGI-like isn't the best way to describe it. I know there's for example AJP but that appears to be aimed specifically at Java. AJP is part of the proxy framework. It's written by the java (tomcat) folks for their own use, but if you have a non-java AJP server, there's nothing to stop you using it for that. An official module would be handy so that PHP can be run in separate processes without requiring the http server itself to use separate processes. I can't see how that's of much use except in the case of a server which uses a little PHP but mostly runs some application that benefits substantially from a threaded MPM. What would you need that isn't provided for by KeepAliveTimeout is 15 by default. I guess/think the majority of processes is idle during most ( 50%) of the time. I'm not sure, but don't these idle processes still consume a lot of memory and (persistent database connection) resources? A separate process would also allow you to run PHP with other user IDs and process priorities/privileges and provide fault isolation (apache process/connection doesn't crash when PHP does). running PHP as CGI, under fastcgi, or on a separate server instance running with prefork and proxied by the primary server? PHP as CGI causes too much overhead I think. Proxying the entire server would be an option but a bit of overkill I think.
Re: Any 'official' Apache FastCGI-like alternative planned?
On 11/28/05, Nick Kew [EMAIL PROTECTED] wrote: On Sunday 27 November 2005 23:09, Olaf van der Spek wrote: Nope. There's the old mod_fastcgi and the more up-to-date mod_fcgid out there. Why does the world need another? But not in the official Apache distribution. How is that a problem? It means the module is available on far less hosts. And with non-dedicated hosts that's a significant issue (I think). And not with a Debian/DFSG-free license. Huh? If debian has taken to rejecting the GPL, what do they have left? Not the Linux or Hurd kernels, for starters. Oops, I assumed you referred to the one from http://fastcgi.com/ KeepAliveTimeout is 15 by default. I guess/think the majority of processes is idle during most ( 50%) of the time. I'm not sure, but don't these idle processes still consume a lot of memory and (persistent database connection) resources? Yep. Shifting that overhead to fastcgi doesn't get rid of it - unless Why not? Fastcgi isn't tied up during the keep alive idle time. (as I suggested) the PHP is a small proportion of total traffic, so the fastcgi can be a lot smaller than the main server. But then, the same applies to proxying another Apache instance. A separate process would also allow you to run PHP with other user IDs and process priorities/privileges and provide fault isolation (apache process/connection doesn't crash when PHP does). Sounds like fastcgi will suit you nicely. I still don't see the problem. No problem indeed if fastcgi is being used. I thought you were arguing for just using the prefork mpm. (BTW, I sent the mod_fcgid maintainer a patch to build cleanly with Apache 2.1.8/9 a few weeks ago. Hopefully he'll review and apply it). running PHP as CGI, under fastcgi, or on a separate server instance running with prefork and proxied by the primary server? PHP as CGI causes too much overhead I think. That would depend on the volume of PHP usage. Of course.
Re: SSL enabled - nokeepalive in MSIE for non-SSL connections
On 11/3/05, Olaf van der Spek [EMAIL PROTECTED] wrote: Joe Orton wrote: All versions need unclean shutdown at least, not sure about keepalive. If you have new data to provide on this front that's great and very welcome, please send it to [EMAIL PROTECTED] bugzilla is not a discussion or support forum, however. I've been running without SetEnvIf User-Agent .*MSIE.* \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 for a few months now and I haven't encountered any issues with IE. So I think it's safe to drop this work around. Will this be changed in the default configuration?
Re: [VOTE] 2.1.10 as GA
On 11/21/05, Brad Nicholes [EMAIL PROTECTED] wrote: +1 for beta status on NetWare. This will probably also be a +1 for GA as well as long as nothing significant turns up over the next several days of testing. Will there be (beta) Windows binaries available before it become GA? I wouldn't mind testing but I do mind compiling myself.
Re: SSL enabled - nokeepalive in MSIE for non-SSL connections
On 11/21/05, Joshua Slive [EMAIL PROTECTED] wrote: Olaf van der Spek wrote: On 11/3/05, Olaf van der Spek [EMAIL PROTECTED] wrote: Joe Orton wrote: All versions need unclean shutdown at least, not sure about keepalive. If you have new data to provide on this front that's great and very welcome, please send it to [EMAIL PROTECTED] bugzilla is not a discussion or support forum, however. I've been running without SetEnvIf User-Agent .*MSIE.* \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 for a few months now and I haven't encountered any issues with IE. So I think it's safe to drop this work around. Will this be changed in the default configuration? I think we still need to see a couple people running large, general-interest, ssl-enabled websites post their results. Why is that needed? Wouldn't changing the default configuration not affect existing sites as those keep their existing configuration?
Re: SSL enabled - nokeepalive in MSIE for non-SSL connections
On 11/22/05, Joshua Slive [EMAIL PROTECTED] wrote: Why is that needed? Wouldn't changing the default configuration not affect existing sites as those keep their existing configuration? Yes. But I still have not seen a very clear statement that this configuration is no longer needed in general. That's what I am looking for: evidence that MSIE works properly on large sites without this present. But how do you expect to gather this evidence (without changing the default config)?
Re: SSL enabled - nokeepalive in MSIE for non-SSL connections
On 11/5/05, Marc Stern [EMAIL PROTECTED] wrote: It's a bit more complex than that. At a certain point, a fix was released for IE 6 to correct the incompatibility that needed the 'ssl-unclean-shutdown' directive (I guess it's KB 831167). At this point, we had two different flavours of IE+SSL floating around. Although we can determine if the browser is IE 4, 5, or 6, it seems impossible to determine if the mentionned fix was applied or not on a IE 6 browser. The biggest problem is that, if you add the directive, the latest versions of IE 6 cannot establish the SSL session. Wasn't that update published in February 2004? In that case I think it's safer to assume you're dealing with the new version than the old version.
Re: SSL enabled - nokeepalive in MSIE for non-SSL connections
On 11/4/05, Joe Orton [EMAIL PROTECTED] wrote: On Thu, Nov 03, 2005 at 03:37:10PM +0100, Olaf van der Spek wrote: Joe Orton wrote: All versions need unclean shutdown at least, not sure about keepalive. If you have new data to provide on this front that's great and very welcome, please send it to [EMAIL PROTECTED] bugzilla is not a discussion or support forum, however. I've been running without SetEnvIf User-Agent .*MSIE.* \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 for a few months now and I haven't encountered any issues with IE. So I think it's safe to drop this work around. Intesting to hear, thanks. What range of MSIE versions are hitting your SSL site? It's only a small SSL site, used for administration tasks by a few people. I've been using the latest versions of IE6 so based on that I know the issue doesn't affect all IE versions (while the SetEnvIf matches all versions).
Re: SSL enabled - nokeepalive in MSIE for non-SSL connections
Joe Orton wrote: All versions need unclean shutdown at least, not sure about keepalive. If you have new data to provide on this front that's great and very welcome, please send it to [EMAIL PROTECTED] bugzilla is not a discussion or support forum, however. I've been running without SetEnvIf User-Agent .*MSIE.* \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 for a few months now and I haven't encountered any issues with IE. So I think it's safe to drop this work around.
Re: SSL enabled - nokeepalive in MSIE for non-SSL connections
On 11/3/05, Anish Mistry [EMAIL PROTECTED] wrote: On Thursday 03 November 2005 09:37 am, Olaf van der Spek wrote: Joe Orton wrote: All versions need unclean shutdown at least, not sure about keepalive. If you have new data to provide on this front that's great and very welcome, please send it to [EMAIL PROTECTED] bugzilla is not a discussion or support forum, however. I've been running without SetEnvIf User-Agent .*MSIE.* \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 for a few months now and I haven't encountered any issues with IE. So I think it's safe to drop this work around. Same here. This was also causing some funky behavior for my web application when running over SSL with IE6 clients downloading files. Removing this fixed the problem. Just wondering, what kind of funky behaviour?
Re: How long until 2.2
On 8/9/05, Ian Holsman [EMAIL PROTECTED] wrote: cost of devoting a senior engineer for the next month or two to help 'field test' apache 2.2 in a high scale environment, identifying and submitting patches to 2.2 is Y. Just wondering, when will Win32 binaries of 2.1/2.2 be available for testing?
Re: endless loop trying to create ssl_scache (2.0.54)
On 5/22/05, Jeroen Massar [EMAIL PROTECTED] wrote: stat64(/var/run/apache2/ssl_scache, 0xb8a0) = -1 ENOENT (No such file or directory) open(/var/run/apache2/__db.ssl_scache, O_RDWR|O_CREAT|O_EXCL| O_LARGEFILE, 0644) = -1 EEXIST (File exists) /var/run/apache2/ssl_scache /var/run/apache2/__db.ssl_scache Why do those two differ?
Re: Single-threaded/non-blocking frontend and multi-threaded/processed backend
On 4/13/05, Paul Querna [EMAIL PROTECTED] wrote: Olaf van der Spek wrote: Hi, I originally posted this feature request to the bug tracker, but Joe Orton suggested it'd post it here instead, so here it is. I'd like to see a new 'MPM' that basically works like this: A single or few-threaded, non-blocking frontend that accepts incoming connections, receives requests and sends responses. A multi-threaded or multi-processed backend that processes requests, generates responses and passes the responses to the frontend for sending to the client. The advantage of this scheme would be that you can handle a (much) bigger number of clients/persistent connections with less resources. The event MPM is a step in the right direction, but not 'good' enough. A scenario with multiple backends may be possible to, for example one running as user A, one as user B, etc. Or one multi-threaded backend for static content and one multi-processed backend for dynamic content (PHP). http://issues.apache.org/bugzilla/show_bug.cgi?id=32243 I agree with just about everything you said, at least in concept. I am willing to help out, but I don't have the time or resources to head up this type of project right now. If you do the initial work, I would love to help get such an MPM into the mainline tree. Wouldn't it be possible to start this 'transition' by writing a module that forwards the request to a separate backend process? That way, you could safely run the threaded MPM and still use PHP in a safe way.
Re: Single-threaded/non-blocking frontend and multi-threaded/processed backend
On 5/10/05, Phillip Susi [EMAIL PROTECTED] wrote: Why have a separate 'frontend' and 'backend'? Because for example PHP is not thread-safe and PHP may (easily) crash (and you don't wish to allow that to crash the entire server). Or because you wish to run one backend as user A and another backend as user B.
Re: Post-2.2 Thoughts
On 5/8/05, Phillip Susi [EMAIL PROTECTED] wrote: I like this idea. I think one of the best and most important things that apache is doing these days is trying to migrate away from being a web server and towards a generic server platform. Eventually I would like to be able to run apache to serve web content, email ( smtp as well as pop3 ), and subversion repositories and other file shares ( possible pop3? What happened to imap? I'm not quite sure what you mean here, but that is probably because I'm new to hacking on apache, so forgive me if this is a stupid question. As I understand it now, the MPM receives data from the socket and places it into a bucket, attaches the bucket to the brigade, and calls the lowest level filter, passing it the bucket. Each filter in the chain then can modify the brigade, and can pass the bucket to the next filter, or possibly call back down the chain to the mpm to get more data. Eventually the brigade makes it to the handler which forms a reply and passes it back down the chain to the mpm to send out on the socket. Is this about correct? Where do workers fit in? I'd guess the socket handling code would be single-threaded. But you can't block the entire server to handle a single request, so the request would be handled in a thread of even another process.
Re: mod_cache caching the 301 Moved Permanently
On 4/22/05, Justin Erenkrantz [EMAIL PROTECTED] wrote: On Thu, Apr 21, 2005 at 10:04:54AM +0530, Devendra Singh wrote: Hi, I am writing to the Developer List because I did not get any response on the Users List and thought that the topic might be relevant to the dev list. If a request comes for a directory w/o trailing slash, it gets cached and the subsequent requests see: Moved Permanently The document has moved here for try to access the URL: http://www.beach-clothing.com/where-to-buy I don't get it. What's your problem? -- justin The 'here' link is to http://www.beach-clothing.com:8080/where-to-buy/ while he wants it do be to http://www.beach-clothing.com/where-to-buy/
Re: Reading byte to byte from client request
On 4/20/05, Ivan Barrera A. [EMAIL PROTECTED] wrote: no chance ? Why not use the time since the start of the request instead?
Re: Reading byte to byte from client request
On 4/20/05, Ivan Barrera A. [EMAIL PROTECTED] wrote: Olaf van der Spek wrote: On 4/20/05, Ivan Barrera A. [EMAIL PROTECTED] wrote: no chance ? Why not use the time since the start of the request instead? Ok.. i tought about that, but the problem arises when i need to check every byte. Why ? , because my input filter is getting control over when a line is entered. With a little perl script, i'm opening a socket and putting the same char over and over, with 2 seconds of delay between them. As i never put a CR-LF, my mod never gets the control to see this delay :( I don't think an input filter is the appropriate place to do time out checks.
Re: Single-threaded/non-blocking frontend and multi-threaded/processed backend
On 4/13/05, Paul Querna [EMAIL PROTECTED] wrote: Olaf van der Spek wrote: Hi, I originally posted this feature request to the bug tracker, but Joe Orton suggested it'd post it here instead, so here it is. I'd like to see a new 'MPM' that basically works like this: A single or few-threaded, non-blocking frontend that accepts incoming connections, receives requests and sends responses. A multi-threaded or multi-processed backend that processes requests, generates responses and passes the responses to the frontend for sending to the client. The advantage of this scheme would be that you can handle a (much) bigger number of clients/persistent connections with less resources. The event MPM is a step in the right direction, but not 'good' enough. A scenario with multiple backends may be possible to, for example one running as user A, one as user B, etc. Or one multi-threaded backend for static content and one multi-processed backend for dynamic content (PHP). http://issues.apache.org/bugzilla/show_bug.cgi?id=32243 I agree with just about everything you said, at least in concept. I am willing to help out, but I don't have the time or resources to head up this type of project right now. If you do the initial work, I would I'm afraid I don't have the experience with the Apache code to do this. love to help get such an MPM into the mainline tree. -Paul
Single-threaded/non-blocking frontend and multi-threaded/processed backend
Hi, I originally posted this feature request to the bug tracker, but Joe Orton suggested it'd post it here instead, so here it is. I'd like to see a new 'MPM' that basically works like this: A single or few-threaded, non-blocking frontend that accepts incoming connections, receives requests and sends responses. A multi-threaded or multi-processed backend that processes requests, generates responses and passes the responses to the frontend for sending to the client. The advantage of this scheme would be that you can handle a (much) bigger number of clients/persistent connections with less resources. The event MPM is a step in the right direction, but not 'good' enough. A scenario with multiple backends may be possible to, for example one running as user A, one as user B, etc. Or one multi-threaded backend for static content and one multi-processed backend for dynamic content (PHP). http://issues.apache.org/bugzilla/show_bug.cgi?id=32243
