search

moinwiki / moin

MoinMoin Wiki Development (2.0+), unstable, for production please use 1.9.x.
https://moinmo.in/
Other
307 stars 92 forks source link

uwsgi / redirect not working #819

Open kwatsen opened 5 years ago

kwatsen commented 5 years ago

The built-in server is okay, but when configuring to use WSGI (see issue #818), GET on '/' does NOT return "/Home":

Here the first request (response okay):

$ curl http:/10.0.2.5
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a href="http://10.0.2.5/">http://10.0.2.5/</a>.  If not click the link.

Here's the second request (response NOT okay):

$ curl  http:/10.0.2.5/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a href="http://10.0.2.5/">http://10.0.2.5/</a>.  If not click the link.

Everything (links, etc.) works after manually changing the URL to "/Home":

<!DOCTYPE html>
<html>
    <SNIPPED/>
</html>
RogerHaase commented 5 years ago

On my website, moin is not running at root. My results:

roger@meerkat:~$ curl https://digitalrockart.org/moin
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a href="http://digitalrockart.org/moin/">http://digitalrockart.org/moin/</a>.  If not click the link.roger@meerkat:~$

I think the above is correct, a trailing / is required. When I add it:

roger@meerkat:~$ curl https://digitalrockart.org/moin/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a href="/moin/Home">/moin/Home</a>.  If not click the link.roger@meerkat:~$

Assuming you have not changed wikiconfig.py, is there a uwsgi conf file?

kwatsen commented 5 years ago

Hi Roger,

Thanks for the response. I’ll share my uwsgi.ini file tonight.

Is your server using the built-in webserver, or is it using cgi, fcgi, or wsgi behind a webserver?

I think that digitalrockart.org (not the /moin/ subdir) is running 1.9. I must be confused because I thought you indicated before that it was running 2.0.

Sorry about the commit not having the “fixes” statements. That would be in the PR ‘description’ statement (not the individual ‘commit’ statements), right?

What’s happening, currently, is that I go to GitHub and it offers to do a PR. I fill in the ‘description‘ statement and submit. In the background GH creates the Issue # and uses my PR description stmt as the Issue description...

Kent

Sent from my iPhone

On Apr 14, 2019, at 12:16 PM, RogerHaase notifications@github.com wrote:

On my website, moin is not running at root. My results:

roger@meerkat:~$ curl https://digitalrockart.org/moin <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

Redirecting...

Redirecting...

You should be redirected automatically to target URL: http://digitalrockart.org/moin/. If not click the link.roger@meerkat:~$ I think the above is correct, a trailing / is required. When I add it: roger@meerkat:~$ curl https://digitalrockart.org/moin/ Redirecting...

Redirecting...

You should be redirected automatically to target URL: /moin/Home. If not click the link.roger@meerkat:~$ Assuming you have not changed wikiconfig.py, is there a uwsgi conf file? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

RogerHaase commented 5 years ago

My production rockart application is running moin 1.9, a really old Webware For Python app and a couple of other apps for serving jpg images, and svg images. I am in the process of converting all of that to moin2 by rewriting all the Webware for Python transactions into a moin2 app. Progress is slow, as I seem to enjoy working on moin more than working on digitalrockart.

I also get confused by github, I thought I was responding to the commit 818, then discovered it was issue 818, then tried to delete my comment, and I think I deleted the entire 818 issue. Was 818 the number for both the issue and the commit? I will have to try your way.

The way I do is to commit locally (with the commit message starting with (fixes #nnn if there is a prior issue), then git push, then get on git hub and do the PRs, usually without comment as the commit message tells enough.

The digitalrockart web site is running on a Webfaction server running CentOS. I think it is running ngix in front of apache. I have an apache conf file where I set up my various apps.

On Sun, Apr 14, 2019 at 9:41 AM Kent Watsen notifications@github.com wrote:

Hi Roger,

Thanks for the response. I’ll share my uwsgi.ini file tonight.

Is your server using the built-in webserver, or is it using cgi, fcgi, or wsgi behind a webserver?

I think that digitalrockart.org (not the /moin/ subdir) is running 1.9. I must be confused because I thought you indicated before that it was running 2.0.

Sorry about the commit not having the “fixes” statements. That would be in the PR ‘description’ statement (not the individual ‘commit’ statements), right?

What’s happening, currently, is that I go to GitHub and it offers to do a PR. I fill in the ‘description‘ statement and submit. In the background GH creates the Issue # and uses my PR description stmt as the Issue description...

Kent

Sent from my iPhone

On Apr 14, 2019, at 12:16 PM, RogerHaase notifications@github.com wrote:

On my website, moin is not running at root. My results:

roger@meerkat:~$ curl https://digitalrockart.org/moin <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

Redirecting...

Redirecting...

You should be redirected automatically to target URL: http://digitalrockart.org/moin/. If not click the link.roger@meerkat:~$ I think the above is correct, a trailing / is required. When I add it: roger@meerkat:~$ curl https://digitalrockart.org/moin/ Redirecting...

Redirecting...

You should be redirected automatically to target URL: /moin/Home. If not click the link.roger@meerkat:~$ Assuming you have not changed wikiconfig.py, is there a uwsgi conf file? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/moinwiki/moin/issues/819#issuecomment-483013936, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGODHUINQY6MXXPF6TJ6RTPQNNFBANCNFSM4HFYKZOQ .

kwatsen commented 5 years ago

Hi Roger,

I should've mentioned before that, in total, I performed two GitHub actions:

  1. first I "implicitly" created #818, via a PR like, I mentioned before. The PR was to share the fix I made to the moin2.wsgi file, in case anyone wanted to reproduce my results. This PR request is what you merged.

  2. then I created another issue, this issue, #819. When I created this issue, I put a see issue #818 into the description statement. So now, when you look at #818, GitHub promenantly displays that #819 references it, which it does, but not in a "fixes" sort of a way. I think this is where the mixup is occurring.

The uwsgi.ini file I'm using is below. Note: I left my commented-out lines to illustrate other knobs I've been twiddling:

[uwsgi]
master = true
#vhost = true
enable-threads = true
processes = 5
#daemonize2 = True

fastcgi-socket = /var/www/run/moinmoin.sock
#fastcgi-modifier1 = 9

chmod-socket = 660
#chown-socket = www:www
#uid = www
#gid = www

chdir = /usr/local/share/moin2/moin
wsgi-file = wiki_local/moin2.wsgi

#master
#workers = 3
max-requests = 200
#harakiri = 30
#die-on-term

The reason the chown-socket, uid, and gid lines are commented out is because it's a known issue on OpenBSD, where use of these options causes a crash. This following file works on OpenBSD, which has its own httpd implementation, much like nginx. So, if you're on another platform, your file will look different:

server "default" {
    listen on * port 80
    location match "^/$" {      <--- BLOCK PROVIDES WORKAROUND SOLN FOR THIS ISSUE
        request rewrite "/Home/"
    }
    location "/*" {
        fastcgi socket "/run/moinmoin.sock"
    }

As you can see above, I added a "block" (3 lines) since opening this issue that provides a workaround. Essentially, I'm telling the external webserver to rewrite requests from '/' to "/Home". So now the external server handles the case, sidestepping Moin.

BTW, my server now returns a message similar to the one your server returns:

$ curl  http://10.0.2.5
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a href="/Home">/Home</a>.  If not click the link.

So my guess is that your external server is similarly rewriting requests. You, since you have it as a virtual host (i.e. request to "/' go to your 1.9 server, and requests to "/moin" go to your 2.0 server.

I wouldn't claim that the issue is "fixed", but it's not a blocker for me anymore. Perhaps prio4? [BTW, what shop are the issues list? when's the last time the list has been scrubbed?"

RogerHaase commented 5 years ago

I do not think the issue is fixed, you should not have to do the rewrite.

I am using a virtual server on a Webfaction CentOS system. Here are the rules dealing with moin2 testing from my httpd.conf file. 

#  ==== MoinMoin2 testing - git repo
WSGIDaemonProcess moin_wsgi processes=1 threads=2 stack-size=524288 python-home=/home/rockart/webapps/web/moin-venv-python2.7
WSGIScriptAlias /moin /home/rockart/webapps/web/moin/moin.wsgi
<Location /moin>
    WSGIProcessGroup moin_wsgi
    ExpiresActive On
    ExpiresDefault "access plus 24 hours"
    # from moinmo.in AutoUpdatingStuff
    ExpiresByType text/html "now plus 1 seconds"
</Location>

If I enter a url without the trailing slash on a browser, my apache log looks like:

"GET /moin HTTP/1.0" 308 269 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
"GET /moin/ HTTP/1.0" 301 240 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
"GET /moin/ HTTP/1.0" 302 227 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
"GET /moin/Home HTTP/1.0" 301 244 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
"GET /moin/Home HTTP/1.0" 200 16359 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"

And if I add the trailing slash:

"GET /moin/ HTTP/1.0" 302 227 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
"GET /moin/Home HTTP/1.0" 301 244 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
"GET /moin/Home HTTP/1.0" 200 16359 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"

The above seems odd to me, either the 301 or 302 seems redundant. I repeated the tests with Firefox, Chrome, Opera, IE11 and Edge; all had the same results so it is not a browser issue.