I too have had some recent problems with mod_webkit. It's a long story: Our original configuration was:
A) Apache 1.3.X / mod_webkit running on Debian Sarge communicating with WebKit on Windows 2000. This configuration worked fine. However, we needed to replace the Windows server, and we chose to replace it with a Windows 2003 server. So our new configuration was: B) Apache 1.3.X / mod_webkit running on Debian Sarge communicating with WebKit on Windows 2003. In this configuration, all responses longer than 8K got truncated, so this was unusable. I was never able to figure out which component was causing the truncation. The next thing we tried was: C) Apache 2.0.X / mod_webkit2 running on Debian Sarge communicating with WebKit on Windows 2003. This configuration at first seemed to work OK, but then we noticed occasional malfunctions -- HTTP headers showing up in the body of a response, occasional timeouts in mod_webkit2 attempting to connect to the appserver, and so forth. These problems also happened when we used Windows 2000 instead of 2003, so that points to a buggy mod_webkit2. Finally we decided to try abandoning mod_webkit entirely: D) Apache 1.3.X / mod_rewrite / mod_proxy running on Debian Sarge communicating with WebKit on Windows 2003 using HTTP This configuration has been working great for over a month. For us, using the native HTTP server in WebKit via proxying has proven to be very robust -- much more so than mod_webkit. The only drawback is that we lose the "queue up requests and retry" functionality in mod_webkit that is helpful when you need to restart the appserver, but we hardly ever restart the appserver anyhow. Based on this recent experience, I would lkean toward recommend the native HTTP server via proxying as the "standard" deployment mechanism. However, I should note that we had no problems with configuration A at all -- the problems only started when we moved the WebKit appserver to Windows 2003. However, my gut feeling is that change to Win2003 probably exposed a latent bug in mod_webkit rather than some sort of bug in Windows 2003 or in WebKit itself. (Another reason to prefer using HTTP proxying is that the C code in mod_webkit and mod_webkit2 is difficult to comprehend, I have no way to tell if the Apache API's are being used correctly, and would have a tough time fixing bugs. I feel confident that the HTTP proxying functionality of Apache is very well battle-tested, and if the HTTP server functionality in WebKit were to be found to be buggy, I'd have a much easier time fixing it since it's pure Python.) - Geoff ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Webware-discuss mailing list Webware-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
