metashare.fcgi appearing in links generated by Django

May 21, 2013 at 11:57

Following the installation manual, I set up meta-share 3.0.1 with postgresql and lighttpd with default ports 9191 for lighttpd and 9190 for Dango. The homepage appears fine on http://my-test-server:9191/ (after testing, I will move to SSL / https on the standard port).

However, the html code contains links such as a href="/metashare.fcgi/repository/search/" which means that the user is sent to http://my-test-server:9191/metashare.fcgi/repository/search/ after clicking on "Browse Resources". There are 2 issues here:

 (1) Other metashare installations, such as DFKI's installation, do not show the "metashare.fcgi" path component to the public.

 (2) The default lighttpd configuration that comes with the metashare 3.0.1 download does not handle such requests correctly, causing an error message. Turning on debug messages, Django reports:

Page not found (404)Request Method:         GETRequest URL:    http://136.206.11.64:9191/metashare.fcgi/metashare.fcgi/repository/search/

Using the URLconf defined in metashare.urls, Django tried these URL patterns, in this order: [list of patterns; including a pattern for ^repository/]

The current URL, metashare.fcgi/repository/search/, didn't match any of these.

-- END of Django error message. --   Note that the string "/metashare.fcgi" is duplicated in the request URL. As a workaround, I added a "rewrite-once" rule to lighttpd so that lighttpd does not add another "/metashare.fcgi" if it is already present, but issue (1) remains.

The above error message confirms that Django correctly removes the first "metashare.fcgi" component from the URL before attempting to match URL patterns as the "current URL" only contains it once. Furthermore, the provided configuration for lighttpd clearly adds "metashare.fcgi" to the initial request for the homepage and the homepage loads ok. This, and the fact that my workaround for (2) workds, all indicates that Django is supposed to receive a request with "metashare.fcgi" as the first component and nonetheless emit ULRs that do not contain it. This suggests that the issue is NOT with lighttpd. Instead, this may be an issue with how Django handles fastcgi requests. Maybe something changed in the underlying python-flup module?

Tags: installation

Discussion 1 answers

  • avatar
    Answer by juli on Jul 04, 2013 at 12:45

    Dear Joachim,you should uncomment the FORCE_SCRIPT_NAME setting in the local_settings.py file.As you will read in the META-SHARE installation manual, this is required when the META-SHARE node is deployed using FastCGI and for example lighttpd. There is a known bug with FCGI hosted applications and lighttpd; it basically messes up the URL after HTTP submits. FORCE_SCRIPT_NAME= ""fixes the issue and hence is required for lighttpd use.Best,Juli Bakagianni

  • avatar
    Log in or Register to reply to this post.