This project is read-only.


Jul 8, 2009 at 6:24 AM
Edited Jul 8, 2009 at 6:26 AM

It might be interesting to support SCGI described at:

This would enable various technologies to sit behind the web server. Other light weight web servers such as lighttpd and nginx have this.


Just an idea,



Jul 8, 2009 at 8:50 AM

yes. I'll create a implementation when I get back from my vacation.

Aug 10, 2009 at 1:27 PM

I've started with the implementation but I don't fully understand how the response from the SCGI server looks like. Can someone be kind and post a example reply?

Aug 10, 2009 at 6:21 PM

Sure. It's the full HTTP response:


Status: 200 OK

Content-Type: text/html


<html><body><p>Hello, world.</p></body></html>


So the server does not have to do anything fancy; just pass the textual response in whole.


Also, here is a dump of the key/value pairs passed by an actual web server's scgi support:

That's not the actual format, just the key/value pairs printed by a little scgi program I wrote.


Aug 11, 2009 at 6:39 AM

That isn't a valid HTTP response. I guess I have to parse the SCGI response and create a proper HTTP response.


Aug 11, 2009 at 8:20 AM

Sorry, should have said:

HTTP/1.0 200 OK

In any case, it was just an example that I whipped up. It's up to the SCGI program to generate a valid HTTP response. Don't be distracted by my malformed example.


Aug 11, 2009 at 10:54 AM
Edited Aug 11, 2009 at 10:55 AM

It's just not your example. It's even the example in the original specification.


But if you are sure that the SCGI server will generate a proper response, then I'll be ready with the module today.

Aug 11, 2009 at 1:35 PM

No, you're right. The spec shows the Status: header. I just assumed I had it wrong because I cannot see the point of SCGI returning a partial response. But I see CGI does the same thing as well.

I stand corrected.

Can you reuse your current HTTP header parsing code?