Apache RewriteRule for django

777 views
Skip to first unread message

Bob Kline

unread,
Jan 1, 2012, 9:39:00 PM1/1/12
to Django users
I'm moving a django site to a shared hosting server, where I'll need
to use fastcgi (the site on the original server is using mod_python,
which isn't available on the shared hosting server). I have found the
instructions for setting this up, but it's not working. I'm getting
"The requested URL /appname/appname.fcgi/admin was not found on this
server" (I'm using "appname" instead of the real name). The rewrite
rule is:

RewriteRule ^(.*)$ appname.fcgi/$1 [QSA,L]

In light of this rule, which is taken straight from the Django Book,
I'm not surprised by the error message. All the other RewriteRules
I've seen/used in the past put the requested resource in the query
parameter; for example, Drupal uses

RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

which makes sense: Apache will load index.php and pass it "q=what-you-
asked-for" but in the rule given above for django the forward slash in
the replacement string is going to cause Apache to look for something
that doesn't exist, instead of appname.fcgi, which does exist.

Please tell me what I'm missing!

Thanks!

Tiago de Souza Moraes

unread,
Jan 1, 2012, 10:24:06 PM1/1/12
to django...@googlegroups.com
Hi Bob Kline,

May be that this link help you:
http://teago.futuria.com.br/tip/4/

Tiago

> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>

--
~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.
Tiago de Souza Moraes                       Skype & Gtalk teagom
Enviroment Linux                                 Debian and Ubuntu
Public profile
http://www.linkedin.com/pub/tiago-souza-moraes/32/130/599

Daniel Roseman

unread,
Jan 2, 2012, 5:09:55 AM1/2/12
to django...@googlegroups.com
No, this is correct. But you haven't shown us the rest of the configuration. Do you have FastCGIExternalServer specified correctly?

--
DR.

Bob Kline

unread,
Jan 2, 2012, 7:23:32 AM1/2/12
to django...@googlegroups.com
Thanks for your reply, Daniel.  My reading of the documents you pointed me to was that the FastCGIExternalServer directive goes in the httpd.conf file, to which I don't have access, as I'm setting this up on a shared hosting service.  So I followed the instructions pointed to by the note further up on that page ("If you’re on a shared hosting system, you’ll probably be forced to use Web server-managed FastCGI processes. See the section below on running Django with Web server-managed processes for more information").  Those instructions say:

"Many shared-hosting providers don't allow you to run your own server daemons or edit the httpd.conf file. In these cases, it's still possible to run Django using Web server-spawned processes.

"If you're using Web server-spawned processes, as explained in this section, there's no need for you to start the FastCGI server on your own. Apache will spawn a number of processes, scaling as it needs to."

"In your Web root directory, add this to a file named .htaccess:

AddHandler fastcgi-script .fcgi
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ mysite.fcgi/$1 [QSA,L]

"Then, create a small script that tells Apache how to spawn your FastCGI program. Create a file mysite.fcgi and place it in your Web directory, and be sure to make it executable: ...."

So, my .htaccess file looks just like that (with "mysite" replaced with the real name of the script). The part I don't understand is the slash between the script name and the placeholder $1. The way the filesystem syntax works, that slash tells Apache (and indirectly, the OS) that mysite.fcgi is a directory name, but it's a file, which Apache won't be able to find if it thinks mysite.fcgi is a directory in which it's supposed to find the requested resource (whatever's plugged in for the "$1" placeholder), hence the "not found" message. I'm sure there's a simple piece I'm missing here, but I just don't see it.



Bob Kline

unread,
Jan 2, 2012, 7:32:37 AM1/2/12
to django...@googlegroups.com
Thanks, Tiago.  Unfortunately I don't understand enough Portuguese to get the full benefit of the page you pointed me to.  It appears that your using WSGI on a server on which you have root access, whereas I'm moving the app to a shared hosting server where I can't edit httpd.conf, and I'm using fastcgi.  I do see, however, that your .htaccess file has the same syntax for the RewriteRule as the rule I'm using, and that's the part that has me puzzled.  If the RewriteRule ends up telling Apache that the resource name is "myscript.fcgi/whatever" won't Apache (and the OS) think that myscript.fcgi is a directory name and that the resource is a file in that directory called "whatever"?  That's what the slash means, right?

Dan Poirier

unread,
Jan 2, 2012, 11:39:33 AM1/2/12
to django...@googlegroups.com
On Mon. 2012-01-02 at 07:23 AM EST, Bob Kline <bkl...@rksystems.com> wrote:

> So, my .htaccess file looks just like that (with "mysite" replaced
> with the real name of the script). The part I don't understand is the
> slash between the script name and the placeholder $1. The way the
> filesystem syntax works, that slash tells Apache (and indirectly, the
> OS) that mysite.fcgi is a directory name, but it's a file, which
> Apache won't be able to find if it thinks mysite.fcgi is a directory
> in which it's supposed to find the requested resource (whatever's
> plugged in for the "$1" placeholder), hence the "not found" message.
> I'm sure there's a simple piece I'm missing here, but I just don't
> see it.

Apache doesn't quite work that way. If the part before a slash
corresponds to a file, it'll use that file and pass the rest to the
request processor.

Bob Kline

unread,
Jan 2, 2012, 12:47:02 PM1/2/12
to django...@googlegroups.com
On Mon, Jan 2, 2012 at 11:39 AM, Dan Poirier <poi...@pobox.com> wrote:

> Apache doesn't quite work that way. If the part before a slash
> corresponds to a file, it'll use that file and pass the rest to the
> request processor.

Ah, very clever. I can confirm what you say by changing the
AddHandler directive from

AddHandler fcgid-script .fcgi

to

AddHandler cgi-script .fcgi

So, when Apache was telling me (when the first version of the
AddHandler directive was in play) "The requested URL
"/appname.fcgi/admin was not found on this server" (the error message
leading me to the incorrect conclusion that Apache interpreted the
file path syntax the same way Unix does) what it really meant was
"your hosting provider hasn't set up mod_fcgid properly." Odd way to
communicate that problem. So I guess I'll have to go back to my
hosting provider and ask why this isn't working, in spite of
documentation on their site implying that it should.

Thank you very much for getting me unstuck from the misleading Apache
error message.

--
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com

Bob Kline

unread,
Jan 4, 2012, 10:43:07 AM1/4/12
to django...@googlegroups.com
On Mon, Jan 2, 2012 at 12:47 PM, Bob Kline <bkl...@rksystems.com> wrote:

> So, when Apache was telling me (when the first version of the
> AddHandler directive was in play) "The requested URL
> "/appname.fcgi/admin was not found on this server" (the error message
> leading me to the incorrect conclusion that Apache interpreted the
> file path syntax the same way Unix does) what it really meant was
> "your hosting provider hasn't set up mod_fcgid properly."  Odd way to
> communicate that problem.  So I guess I'll have to go back to my
> hosting provider and ask why this isn't working, in spite of
> documentation on their site implying that it should.

To close the loop, the problem (as I suspected, once Dan straightened
me out about how Apache interprets URI path names) was that the
hosting service had a mis-configured server. Works now. Thanks
again, everyone. Excellent forum!

Reply all
Reply to author
Forward
0 new messages