X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/d9b4287c9a1fffeda133f92f03e2d6eb73a1d75a..c401b6958af7e12c1c2c46f870691bfb0a998fd3:/doc/bugs/CGI_problem_with_some_webservers.mdwn diff --git a/doc/bugs/CGI_problem_with_some_webservers.mdwn b/doc/bugs/CGI_problem_with_some_webservers.mdwn index 158aa5265..e4b0fd448 100644 --- a/doc/bugs/CGI_problem_with_some_webservers.mdwn +++ b/doc/bugs/CGI_problem_with_some_webservers.mdwn @@ -1,5 +1,5 @@ The "ikwiki.cgi?page=index&do=edit" function has a problem -when running with [[debpkg thttpd]] or [[debpkg mini-httpd]]: +when running with [[!debpkg thttpd]] or [[!debpkg mini-httpd]]: for some reason the headers ikiwiki outputs are transmitted as the page content. Surprisingly, the "do=prefs" function works as expected. @@ -15,6 +15,94 @@ Here is what it looks like in iceweasel: (...) -Ikiwiki runs fine with [[debpkg boa]]. +Ikiwiki runs fine with [[!debpkg boa]]. ---[[JeremieKoenig]] \ No newline at end of file +--[[JeremieKoenig]] + +It doesn't work for signin either. +What is the reason for these "header => 1" in FormBuilder initialisations? +Why do they appear two times with conflicting values in the very same hashes? + +--[[JeremieKoenig]] + +> Clearly those duplicate header settings are a mistake. But in all cases, the +> `header => 0` came second, so it _should_ override the other value and +> can't be causing this problem. (cgi_signin only sets it to 0, too). +> +> What version of formbuilder are you using? If you run ikiwiki.cgi at the +> command line, do you actually see duplicate headers? I don't: + + joey@kodama:~/html>REQUEST_METHOD=GET QUERY_STRING="page=index&do=edit" ./ikiwiki.cgi + Set-Cookie: ikiwiki_session_joey=41a847ac9c31574c1e8f5c6081c74d12; path=/ + Date: Tue, 14 Aug 2007 18:04:06 GMT + Content-Type: text/html; charset=utf-8 + + Do thttpd and mini-httpd perhaps not realize that Set-Cookis is the start of +> the headers? --[[Joey]] + +>> Thanks for your help: I think I found the problem! +>> Ikiwiki outputs (in my case) the following +>> error message on stderr, followed by an empty line: + + /srv/ikiwiki/wc/index.mdwn: (Not a versioned resource) + +>> Probably thttpd and mini-httpd read stderr as well as stdout, while apache +>> and boa don't. When using a shell-script wrapper as the CGI, +>> which redirects ikiwiki's error output to /dev/null, it works better. + +>> The edit still fails to commit, because in my wiki, index.mdwn is +>> pulled from the base wiki and somehow ikiwiki wants to change it +>> rather that create it. + +>> --[[JeremieKoenig]] + +>>> If thttpd and mini-httpd interpret CGI's stderr as stdout, then +>>> they're not properly following the CGI spec, and will break with tons +>>> of cgi scripts besides ikiwiki. And of course there are many many cases +>>> where ikiwiki might output to stderr, and that's the right thing to do. +>>> So I don't see any way to address this in ikiwiki. --[[Joey]] + +>>>> (reported as [[!debbug 437927]] and [[!debbug 437932]]) --[[JeremieKoenig]] + +Marking [[done]] since it's not really an ikiwiki bug. --[[Joey]] + +---- + +I'm using boa and getting some odd behaviour if I don't set the `umask` +option in the config file. Editing a page through the web interface and +hitting "Save Page" regenerates the `index.html` file with no world-read +permissions. As a result, the server serves a "403 - Forbidden" error page +instead of the page I was expecting to return to. + +There are only two ways I found to work around this: adding a `umask 022` +option to the config file, or re-compiling the wiki from the command line +using `ikiwiki --setup`. Setting up a git back-end and re-running `ikiwiki +--setup` from inside a hook had no effect; it needed to be at the terminal. +--Paul + +> Since others seem to have gotten ikiwiki working with boa, +> I'm guessing that this is not a generic problem with boa, but that +> your boa was started from a shell that had an unusual umask and inherited +> that. --[[Joey]] + +>> That's right; once I'd worked out what was wrong, it was clear that any +>> webserver should have been refusing to serve the page. I agree about the +>> inherited umask; I hadn't expected that. Even if it's unusual, though, it +>> probably won't be uncommon - this was a stock Ubuntu 9.04 install. --Paul + +(I'm new to wiki etiquette - would it be more polite to leave these details +on the wiki, or to remove them and only leave a short summary? Thanks. +--Paul) + +> Well, I just try to keep things understandable and clear, whether than +> means deleting bad old data or not. That said, this page is a bug report, +> that was already closed. It's generally better to open a new bug report +> rather than edit an old closed one. --[[Joey]] + +>> Thanks for the feedback, I've tidied up my comment accordingly. I see +>> your point about the bug; sorry for cluttering the page up. I doubt it's +>> worth opening a new page at this stage, but will do so if there's a next +>> time. The solution seems worth leaving, though, in case anyone else in my +>> situation picks it up. --Paul