From antonio.cipolletti at gmail.com Wed Dec 3 09:09:42 2008 From: antonio.cipolletti at gmail.com (antonio cipolletti) Date: Wed, 3 Dec 2008 15:09:42 +0100 Subject: [FASTCGI] FGCI and Apache 2.2.10 on Win32 Message-ID: <26DA396FEC6C48C58BF552EBA4194CF0@hp8510> Hi Group, i am using the module mod_fastcgi-2.4.6-AP22.dll with apache 2.2.8 on win32 system, for an Italian financial Institution web site. For a lot of reasons, i am planning to move on apache 2.2.10. I have a question: Is the mod_fastcgi-2.4.6-AP22.dll module compatible with apache 2.2.10 on win32 system ? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hanno at hboeck.de Thu Dec 4 08:01:32 2008 From: hanno at hboeck.de (Hanno =?utf-8?q?B=C3=B6ck?=) Date: Thu, 4 Dec 2008 14:01:32 +0100 Subject: [FASTCGI] Status of fastcgi? Message-ID: <200812041401.33149.hanno@hboeck.de> Hi, I wanted to ask if there are any fastcgi-developers at the moment? Bug reports and patches appear on this list, but it seems nobody is taking care of them. As the mailing list even does not have a public archive, it's unlikely anyone will find the patches here-. The last thing that happened was a new webpage for fastcgi, but no code changes happened since then. Can anyone feeling responsible comment on that? If there's no development of fastcgi at the moment, we should at least consider: - let the mailinglist have a public arhive (I think this should be doable by just subscribing some adress to this list that is only for creating the archive) - publish patches posted here somewhere with comments from people using them. But sure, it'd be preferrable if someone from the fastcgi-team could pop up and comment on further development. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail: hanno at hboeck.de http://www.jukss.de/ Jugemdumweltkongress, 27.12.-4.1. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From evilhare at yandex.ru Sat Dec 6 05:55:13 2008 From: evilhare at yandex.ru (evilhare at yandex.ru) Date: Sat, 06 Dec 2008 13:55:13 +0300 Subject: [FASTCGI] Django + FastCGI problem Message-ID: <187241228560913@webmail3.yandex.ru> Hi, I am using Django + Apache (via FastCGI). I've made my own 404 page (404.html in templates dir) and turned debug mode off. When I'm requesting for non-existed page I see my custom error page, but in Apache's log there is something like this: "GET /authors/333.html HTTP/1.1" 200 368 "-" (the return code is 200, not 404). Also I've tried custom error view (handler404 in urls.py): from django.http import HttpResponse def handler404(request): return HttpResponse('qqq', status=404) I see 'qqq' when requesting for non-existed page, but there is still 200 code in logs, not 404. Guy from the hosting support team told me: " the problem here, is that the application is still returning something. The web server still displays content from the dispatch.fcgi script (even though it's nothing). The 404 comes from within your application, which is still running and responding to apache. Unfortunately, there's nothing on our end that can be changed to fix this." But I need 404 error call to report about unexisted page to search bots. Is it possible to fix it? From antonio.cipolletti at gmail.com Sat Dec 6 06:54:24 2008 From: antonio.cipolletti at gmail.com (antonio cipolletti) Date: Sat, 6 Dec 2008 12:54:24 +0100 Subject: [FASTCGI] Status of FastCGI ? Message-ID: Hi, i sent a previous post asking the compatibility of the current fastcgi release and apache 2.2.10 on win32 systems, because i found another group, more.more.more. active than this (www.apachelounge.com ), where there is a different fastcgi module. This site released a different version of fastcgi module : "Because the APR has changed from 1.2 to 1.3, a new mod_fcgid driver is needed. This module mod_fcgid-2.2b works only with Apache 2.2.9 or later (containing APR 1.3.x) Use mod_fcgid-2.2a for Apache 2.2.0 through Apache 2.2.8 (containing APR 1.2.x) ". Anyone can say if there is the same issue on this fastcgi implementation ? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tom at tomdonovan.net Sat Dec 6 09:25:33 2008 From: Tom at tomdonovan.net (Tom Donovan) Date: Sat, 06 Dec 2008 09:25:33 -0500 Subject: [FASTCGI] Status of FastCGI ? In-Reply-To: References: Message-ID: <493A8B5D.7070900@tomdonovan.net> antonio cipolletti wrote: > i sent a previous post asking the compatibility of the current fastcgi > release and apache 2.2.10 on win32 systems, because i found another > group, more?more?more? active than this (www.apachelounge.com > ), > where there is a different fastcgi module. This site released a > different version of fastcgi module : > > ?Because the APR has changed from 1.2 to 1.3, a new mod_fcgid driver is > needed. mod_fcgid (with a "d") from http://fastcgi.coremail.cn/download.htm is indeed a different module. > Anyone can say if there is the same issue on this fastcgi implementation ? The same change is needed in this mod_fastcgi. The changes necessary to run mod_fastcgi with Apache 2.2.9+ on Windows are in the November 2008 snapshot at http://www.fastcgi.com/dist/ The filename is: mod_fastcgi-SNAP-0811090952.tar.gz If you build mod_fastcgi from this source code tarball, it will work with Apache 2.2.9 or higher on Windows. See this previous thread: http://thread.gmane.org/gmane.comp.web.fastcgi.devel/2531 -tom- From jsprenkle at gmail.com Sun Dec 7 17:18:41 2008 From: jsprenkle at gmail.com (Jay Sprenkle) Date: Sun, 7 Dec 2008 16:18:41 -0600 Subject: [FASTCGI] Django + FastCGI problem In-Reply-To: <187241228560913@webmail3.yandex.ru> References: <187241228560913@webmail3.yandex.ru> Message-ID: <1b5f39a10812071418q45441790wa2177da1e6d5e7d1@mail.gmail.com> Is your custom 404 page done as an apache option? It sounds like it is. If you're using django and it doesn't report it as an error then apache's error page will, as you've seen, never get invoked. You need to ask the django developers for the solution here. On Sat, Dec 6, 2008 at 4:55 AM, wrote: > Hi, I am using Django + Apache (via FastCGI). > I've made my own 404 page (404.html in templates dir) and turned debug > mode off. > When I'm requesting for non-existed page I see my custom error page, > but in Apache's log there is something like this: > "GET /authors/333.html HTTP/1.1" 200 368 "-" (the return code is 200, > not 404). > Also I've tried custom error view (handler404 in urls.py): > > from django.http import HttpResponse > > def handler404(request): > return HttpResponse('qqq', status=404) > > I see 'qqq' when requesting for non-existed page, but there is still > 200 code in logs, not 404. > > Guy from the hosting support team told me: > " the problem here, is that the application is still returning something. > The web server still displays content from the dispatch.fcgi script (even > though it's nothing). The 404 comes from within your application, which > is still running and responding to apache. > > Unfortunately, there's nothing on our end that can be changed to fix > this." > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.denton at gmail.com Mon Dec 29 13:44:47 2008 From: greg.denton at gmail.com (Greg Denton) Date: Mon, 29 Dec 2008 10:44:47 -0800 Subject: [FASTCGI] fcgi_i/ostream - deprecated? Message-ID: Does anyone know why the C++ streams are deprecated? They seem to work, but I have only used in non-production under normal conditions, i.e. not under high volume, errors, etc.. Thanks. http://www.fastcgi.com/devkit/include/fcgio.h From eddie at mailforce.net Mon Dec 29 14:23:06 2008 From: eddie at mailforce.net (Eddie) Date: Mon, 29 Dec 2008 12:23:06 -0700 Subject: [FASTCGI] fcgi_i/ostream - deprecated? In-Reply-To: References: Message-ID: <1230578586.5995.0.camel@localhost> On Mon, 2008-12-29 at 10:44 -0800, Greg Denton wrote: > Does anyone know why the C++ streams are deprecated? It looks like the streams were depreciated because they weren't of much use. The stream buffer is however not depreciated and one can just make a std::basic_ostream with the fastcgi stream buffer as the streambuf object. That being said, the stream buffer is not implemented very well. -- Eddie From greg.denton at gmail.com Mon Dec 29 14:31:51 2008 From: greg.denton at gmail.com (Greg Denton) Date: Mon, 29 Dec 2008 11:31:51 -0800 Subject: [FASTCGI] fcgi_i/ostream - deprecated? In-Reply-To: <1230578586.5995.0.camel@localhost> References: <1230578586.5995.0.camel@localhost> Message-ID: "the stream buffer is not implemented very well." Do you know what the issues are? On Mon, Dec 29, 2008 at 11:23 AM, Eddie wrote: > On Mon, 2008-12-29 at 10:44 -0800, Greg Denton wrote: >> Does anyone know why the C++ streams are deprecated? > > It looks like the streams were depreciated because they weren't of much > use. The stream buffer is however not depreciated and one can just make > a std::basic_ostream with the fastcgi stream buffer as the streambuf > object. That being said, the stream buffer is not implemented very well. > -- > Eddie > > From eddie at mailforce.net Mon Dec 29 14:38:21 2008 From: eddie at mailforce.net (Eddie) Date: Mon, 29 Dec 2008 12:38:21 -0700 Subject: [FASTCGI] fcgi_i/ostream - deprecated? In-Reply-To: References: <1230578586.5995.0.camel@localhost> Message-ID: <1230579501.6106.5.camel@localhost> On Mon, 2008-12-29 at 11:31 -0800, Greg Denton wrote: > Do you know what the issues are? Well, I guess it's not fair to say it doesn't work very well. I just don't like it :) I dislike that it neglects the functionality of iostreams in favour of what I perceive as being a somewhat clunky, inefficient and leaky underlying C interface. That's why I like fastcgi ++ ( http://fastcgipp.com ). Bias note: It's my project so I'm not to be trusted. -- Eddie From greg.denton at gmail.com Tue Dec 30 16:59:55 2008 From: greg.denton at gmail.com (Greg Denton) Date: Tue, 30 Dec 2008 13:59:55 -0800 Subject: [FASTCGI] fcgi_i/ostream - deprecated? In-Reply-To: <1230579501.6106.5.camel@localhost> References: <1230578586.5995.0.camel@localhost> <1230579501.6106.5.camel@localhost> Message-ID: So, I cranked up my test program for the first time and started having intermittent problems with peek() using an input fcgi_streambuf (with buffer) in a std::istream. It seems to skip a number of bytes every couple of hundred requests or so. (Eddie, you were right :-| The apache server is using mod_fcgid (http://fastcgi.coremail.cn/) not mod_fastcgi. (This is the result of many hours googling a year or more ago and going with the majority opinion which seemed to be that mod_fcgid was more "reliable" under certain error conditions.) Anyone have a guess at whether it's mod_fcgid or fcgi_streambuf (or the combination), before I start diving into code? Thanks. On Mon, Dec 29, 2008 at 11:38 AM, Eddie wrote: > On Mon, 2008-12-29 at 11:31 -0800, Greg Denton wrote: >> Do you know what the issues are? > > Well, I guess it's not fair to say it doesn't work very well. I just > don't like it :) I dislike that it neglects the functionality of > iostreams in favour of what I perceive as being a somewhat clunky, > inefficient and leaky underlying C interface. That's why I like fastcgi > ++ ( http://fastcgipp.com ). > > Bias note: It's my project so I'm not to be trusted. > -- > Eddie > > From eddie at mailforce.net Tue Dec 30 17:14:26 2008 From: eddie at mailforce.net (Eddie) Date: Tue, 30 Dec 2008 15:14:26 -0700 Subject: [FASTCGI] fcgi_i/ostream - deprecated? In-Reply-To: References: <1230578586.5995.0.camel@localhost> <1230579501.6106.5.camel@localhost> Message-ID: <1230675266.6229.12.camel@localhost> On Tue, 2008-12-30 at 13:59 -0800, Greg Denton wrote: > Anyone have a guess at whether it's mod_fcgid or fcgi_streambuf (or > the combination), before I start diving into code? Thanks. I would guess it is fcgi_streambuf. I have run none-fcgi_streambuf code through some pretty rigorous tests without any issues. I would still recommend testing it out with mod_fastcgi anyway though. I have noticed while analyzing fcgid vs. fastcgi a few minor differences in the way data is communicated. Those differences however seem to be more due to vague parts of the FastCGI specification. -- Eddie