[OS X] FastCGI -> spawned processes (rails, django) return 500 Internal Server Error

[GoogleCodeExporter]

> What steps will reproduce the problem?

1. Install latest Cherokee and rails (or django) on OS X 10.5.x (Leopard)
2. Follow example instructions, i.e. 
http://www.cherokee-project.com/doc/cookbook_ror.html
3. Point browser at http://localhost/example

> What is the expected output? What do you see instead?

Expected:
rails (or django) default site screen

Actual:
500 Internal Server Error

cherokee.error log:
::1 - - [24/Aug/2008:13:08:29 +0000] "GET /example/ HTTP/1.1" 500 0 "-" 
"Mozilla/5.0 
(Macintosh; U; Intel Mac OS X 10_5_4; en-us) AppleWebKit/525.18 (KHTML, like 
Gecko) 
Version/3.1.2 Safari/525.20.1"

> What version of the product are you using? On what operating system?

Latest source release as of 8/24/08: Cherokee 0.8.1
OS: Mac OS X (Leopard) 10.5.4

Please provide any additional information below.

The instructions work perfectly when I tested them on Ubuntu 8.04, seems to be 
platform-
specific. 

Cherokee serves static content just fine, the default page appears as normal. 

Cherokee-admin also works on OS X.

This problem occurs with FastCGI using a rails project, and also with SCGI 
using a django project, 
configured as per the online documentation cited above.

The rails process DOES spawn; after connecting to http://localhost/example and 
getting the 500 
error, I can connect to http://localhost:8000/ and rails is up.

Original issue reported on code.google.com by yazir...@gmail.com on 24 Aug 2008 at 5:18

[GoogleCodeExporter]

Found some more information in mongrel.log:

Sun Aug 24 13:48:32 -0400 2008: HTTP parse error, malformed request 
(127.0.0.1): 
#<Mongrel::HttpParserError: Invalid HTTP format, parsing fails.>
Sun Aug 24 13:48:32 -0400 2008: REQUEST DATA: 
"\001\001\000\001\000\b\000\000\000\001\000\000\000\000\000\000\001\004\000\001\
000\037\0
00\000\017\016SERVER_SOFTWARECherokee 
0.8.1\001\004\000\001\000\025\000\000\v\bSERVER_NAMECherokee\001\004\000\001\000
8\000\000\
020&SERVER_SIGNATURE<address>Cherokee web 
server</address>\001\004\000\001\000\032\000\000\021\aGATEWAY_INTERFACECGI/1.1\0
01\004\000
\001\000#\000\000\004\035PATH/bin:/usr/bin:/sbin:/usr/sbin\001\004\000\001\000*\
000\000\r\eDOC
UMENT_ROOT/Library/WebServer/Cherokee\001\004\000\001\000\020\000\000\v\003REMOT
E_ADDR::1\
001\004\000\001\000\024\000\000\t\tHTTP_HOSTlocalhost\001\004\000\001\000\026\00
0\000\v\tSER
VER_NAMElocalhost\001\004\000\001\000\016\000\000\f\000QUERY_STRING\001\004\000\
001\000\01
7\000\000\v\002SERVER_PORT80\001\004\000\001\000\031\000\000\017\bSERVER_PROTOCO
LHTTP/1.
1\001\004\000\001\000\023\000\000\016\003REQUEST_METHODGET\001\004\000\001\000\r
\000\000
\v\000REMOTE_USER\001\004\000\001\000\f\000\000\t\001PATH_INFO/\001\004\000\001\
000\026\00
0\000\v\tREQUEST_URI/example/\001\004\000\001\000\n\000\000\005\003HTTPSoff\001\
004\000\001
\000p\000\000\vcHTTP_ACCEPTtext/xml,application/xml,application/xhtml+xml,text/h
tml;q=0.9,text/plain
;q=0.8,image/png,*/*;q=0.5\001\004\000\001\000#\000\000\024\rHTTP_ACCEPT_ENCODIN
Ggzip, 
deflate\001\004\000\001\000\e\000\000\024\005HTTP_ACCEPT_LANGUAGEen-
us\001\004\000\001\000\e\000\000\017\nHTTP_CONNECTIONkeep-
alive\001\004\000\001\000\216\000\000\017}HTTP_USER_AGENTMozilla/5.0 
(Macintosh; U; Intel Mac OS X 
10_5_4; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 
Safari/525.20.1\001\004\000\001\000\025\000\000\v\bSCRIPT_NAME/example\001\004\0
00\001\000\0
21\004\000\017\000SCRIPT_FILENAME\000\000\000\000\001\004\000\001\000\000\000\00
0"
---
PARAMS: {}
---

Original comment by yazir...@gmail.com on 24 Aug 2008 at 5:49

[GoogleCodeExporter]

So, Cherokee is trying to talk FastCGI with Rails' HTTP server.

Are you running spawner with the "fastcgi" argument? It looks likes if you were 
not.
That would explain the problem.

I have personally tested Rails on OS X and it worked alright.

Original comment by alobbs on 25 Aug 2008 at 9:32

[GoogleCodeExporter]

I went and doublechecked it, and it is correct:

/Users/dan/src/ruby/example/script/process/spawner fastcgi

But while I was at it, I also went and doublechecked the Django test I tried, 
too, here is the interpreter string 
for that:

/Library/WebServer/Cherokee/clockwork/manage.py runfcgi method=threaded 
host=127.0.0.1 port=3033 
protocol=scgi

Django is configured to use the SCGI handler, hence the protocol argument there 
on the end -- I just set both 
of them up exactly as the documentation did.

/Library/WebServer/Cherokee is the configured webroot, and static content (i.e. 
index.html) serves from it 
properly. The example directories are symbolic links, like in the rails 
documentation. The handlers DO spawn 
their interpreters -- both rails and django start up when I request their URLs.

Here's an interesting new clue I found while verifying all of this though: if I 
start up the interpreter for Django 
by hand, it will connect to it -- it still won't work, I get a 404, but it is a 
Django served 404. Even more 
intriguing... well, check this out:

Using the URLconf defined in clockwork.urls, Django tried these URL patterns, 
in this order:

1. ^clockwork/$

The current URL, clockwork/, didn't match any of these.

I am fairly sure that regex should match, not only from the error, but also 
because it works that way under 
Apache. I also tried it with regexes like "clockwork" and even 
"^.*clockwork.*", as well as explicitly specifying 
the regex strings as r"" or u"", and nothing has yet worked.

Between this issue and the \001\004\000\001 ... stuff that mongrel is reporting 
as seen above, I wonder if 
there could be some sort of string encoding issue going on?  My system locale 
is "en_US.UTF-8" 

Original comment by yazir...@gmail.com on 25 Aug 2008 at 1:24

[GoogleCodeExporter]

I could also confirm the issue of 500 error message on Ubuntu Linux on PPC-64 on
trunk version (0.1.0)

Original comment by antoni.aloy@gmail.com on 9 Oct 2008 at 5:35

[GoogleCodeExporter]

We should re-check issue 501 once this one is solved. I believe they are 
related, and
not just limited to OS X.

Original comment by tah...@gmail.com on 11 Dec 2009 at 12:09