Relevant code snippets: in __init__() I have print >> sys.stderr, self._map as the last thing, in wsgi_app() I have for key in sorted( request.environ.keys() ) : print >> sys.stderr, "%s : %s" % (key, repr( request.environ[key] )) before call to self.dispatch_request()
Here's parts of apache/mod_wsgi log:
[Mon Aug 20 13:16:07 2012] [error] Map([<Rule '/table-editor/upload' -> upload>, [Mon Aug 20 13:16:07 2012] [error] <Rule '/table-editor/print' -> print>, [Mon Aug 20 13:16:07 2012] [error] <Rule '/table-editor/edit' -> edit>, [Mon Aug 20 13:16:07 2012] [error] <Rule '/table-editor/help' -> help>, [Mon Aug 20 13:16:07 2012] [error] <Rule '/table-editor/help/' -> help>, [Mon Aug 20 13:16:07 2012] [error] <Rule '/table-editor' -> new>, [Mon Aug 20 13:16:07 2012] [error] <Rule '/table-editor/' -> new>, [Mon Aug 20 13:16:07 2012] [error] <Rule '/table-editor/<func>' -> update>]) ... [Mon Aug 20 13:16:10 2012] [error] REQUEST_URI : '/table-editor/' ... [Mon Aug 20 13:16:10 2012] [error] werkzeug.request : <Request 'https://octopus.bmrb.wisc.edu/table-editor/' [GET]> ... -- and the result is "404 not found"
Running the same thing w/ run_simple( '127.0.0.1', 5000, ... ) works fine.
I do have 2 more wsgi apps running just fine on that server: trac and my own code not using werkzeug.
On Mon, Aug 20, 2012 at 1:54 PM, Dimitri Maziuk <dmitri.maz...@gmail.com> wrote:
> Here's where it broke (most of this code is copied verbatim from the
> tutorial , BTW):
So if it's getting a 404, it's not matching on any of your routes. You
need to find the cause of that. I would do this to debug:
With the development server, print out the details of the request,
most importantly the path requested (e.g. SCRIPT_NAME and PATH_INFO in
request.environ in your code snippet there).
For the same URL, with mod_wsgi, do the same, print out all of the
request details.
Compare those two, and you should see what is causing the 404 in the
request made to apache.
On Aug 20, 4:03 pm, Simon Sapin <simon.sa...@exyr.org> wrote:
> It would be nice to provide full details of what happened and how you
> solved it. This might help someone who hit a similar issue in the future.
Yes it might. It was, as I originally thought, me missing something
simple, and I solved it pretty much the way you and Steven suggested.
I ran the localhost version at /foo and so I had "/foo", "/foo/bar",
etc. in my Map. And then I set up mod_wsgi with "WSGIScriptAlias /foo
script" without realising mod_wsgi remaps "/foo" to "/" for the
script.
> I ran the localhost version at /foo and so I had "/foo", "/foo/bar",
> etc. in my Map. And then I set up mod_wsgi with "WSGIScriptAlias /foo
> script" without realising mod_wsgi remaps "/foo" to "/" for the
> script.
Let me reword this.
Let s say that mod_wsgi is configured with:
WSGIScriptAlias /foo /var/www/myapp.wsgi
The app is not a the root of the domain. This can be useful if you have multiple apps on the same domain.
Now an HTTP request for http://example.net/foo/bar arrives in Apache.
The path of this request is /foo/bar. It starts with /foo, so it is dispatched to myapp.wsgi.
mod_wsgi will make a WSGI call with an `environ` dictionary. To prepare this dict *it will split the path in two*. environ['SCRIPT_NAME'] is set to '/foo', the part of the path needed to get to the app. environ['PATH_INFO'] is '/bar', the part of the path "inside" the app.
Now the important part: *Werkzeug only uses PATH_INFO to match URL rules*, so that you could move the app to a different prefix without rewriting all the rules. In this case PATH_INFO is /bar; if all the URL rules include the /foo prefix, none will match and Werkzeug will raise a NotFound exception, which shows a 404 error.
The fix is either to remove the /foo prefix in the URL rules, or to install the app at the root of the domain:
WSGIScriptAlias / /var/www/myapp.wsgi
In the latter case SCRIPT_NAME will be empty and PATH_INFO will get the whole request path.
Currently werkzeug's mod_wsgi deployment docs send you "for more
information" to a google code wiki page. Which in turn has a "for
information" pointer right back. ;)
Your write-up should be on one or both of them.
I guess the other missing piece in my posts is that you likely won't
run into this until you add static html file(s) with an href back you
your script (a completely static file upload form in my case). That's
when you'll actually need to know that a) it can't be completely
static, b) it's environ["SCRIPT_NAME"] you need for the url in there,
but c) it's environ["PATH_INFO"] you need for the routing map.
