Unexpected behaviour on bookmarklet submit or related database action

[updated below]

I have a bit of a problem deploying a site on apache with mod_wsgi with some javascript bookmarklet functionality. The problem is that the bookmarklet (which is a browser menu button) submits to a page like

http://stemhub.org/submit/http://the-users-link.com/here

which then returns a form to save metadata about the link. The view function (a flask/werkzeug app) checks the database to see if the link has already been added, and then returns the form with either a pre-existing or newly assigned link id, which I suppose could trigger some kind of timing problem. Very strangely, when I first submit the link, I get the http://stemhub.org/submit/http://the-users-link.com/here page with a "not found" apache error, but if I then reload the page, I get the form as intended. Error logs contain messages about threading exceptions, but they also have these messages when the site performs as expected.

There is a parallel deployment of the app on another port -- stemhub.org:5000 -- that is running on Tornado and works fine, as well as the local development version.

Here are the bookmarklets, on the chance that they are the 开发者_开发问答problem:

working port 5000 version:

javascript:(function(){window.open('http://stemhub.org:5000/submit/'+encodeURIComponent(window.location.href),'height=200,width=150')}())

problem port 80 version:

javascript:(function(){window.open('http://stemhub.org/submit/'+encodeURIComponent(window.location.href),'height=200,width=150')}())

UPDATE: For some reason that belongs to another tag, changing the javascript method encodeURIComponent to encodeURI makes everything work as intended, at least in Firefox and Chrome. Will take Graham Dumpleton's advice about something more sensible for this in the future however.

Whatever your issue is, the way you are putting a second URL within the URL will not work with Apache. This is because Apache will collapse repeating slashes into a single slash and that single slash is then all that the application hosted by Apache will see in PATH_INFO.

In other words, not a mod_wsgi issue and could occur if using other dynamic web application hosting mechanisms in conjunction with Apache, even non Python ones.

BTW, some may point out that the unmodified URL is in REQUEST_URI, but relying on that isn't necessarily a good idea as working out how to split that up and map it against SCRIPT_NAME and PATH_INFO may not always be straight forward depending on whether rewrite rules are used in Apache.

Suggest you instead investigate the second URL being part of a query string and not the URL path.