2007-08-14 19:34:27 +02:00
|
|
|
The "ikwiki.cgi?page=index&do=edit" function has a problem
|
2008-07-21 13:31:04 +02:00
|
|
|
when running with [[!debpkg thttpd]] or [[!debpkg mini-httpd]]:
|
2007-08-14 19:34:27 +02:00
|
|
|
for some reason the headers ikiwiki outputs are transmitted
|
|
|
|
|
as the page content. Surprisingly, the "do=prefs" function
|
|
|
|
|
works as expected.
|
2007-08-14 19:31:53 +02:00
|
|
|
|
|
|
|
|
Here is what it looks like in iceweasel:
|
|
|
|
|
|
|
|
|
|
Set-Cookie: ikiwiki_session_apnkit=99dad8d796bc6c819523649ef25ea447; path=/
|
|
|
|
|
Date: Tue, 14 Aug 2007 17:16:32 GMT
|
|
|
|
|
Content-Type: text/html; charset=utf-8
|
|
|
|
|
|
|
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|
|
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
|
|
|
<html>
|
|
|
|
|
(...)
|
|
|
|
|
|
2008-07-21 13:31:04 +02:00
|
|
|
Ikiwiki runs fine with [[!debpkg boa]].
|
2007-08-14 19:31:53 +02:00
|
|
|
|
2007-08-14 19:53:30 +02:00
|
|
|
--[[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?
|
|
|
|
|
|
2007-08-14 20:06:18 +02:00
|
|
|
--[[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
|
|
|
|
|
|
|
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|
|
|
|
|
|
|
|
|
> Do thttpd and mini-httpd perhaps not realize that Set-Cookis is the start of
|
|
|
|
|
> the headers? --[[Joey]]
|
2007-08-14 20:18:36 +02:00
|
|
|
|
|
|
|
|
>> 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,
|
2007-08-14 20:50:05 +02:00
|
|
|
>> 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.
|
2007-08-14 20:18:36 +02:00
|
|
|
|
|
|
|
|
>> --[[JeremieKoenig]]
|
2007-08-14 22:10:52 +02:00
|
|
|
|
|
|
|
|
>>> 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]]
|
2007-08-14 23:02:07 +02:00
|
|
|
|
2008-07-21 13:31:04 +02:00
|
|
|
>>>> (reported as [[!debbug 437927]] and [[!debbug 437932]]) --[[JeremieKoenig]]
|
2007-08-22 03:06:35 +02:00
|
|
|
|
|
|
|
|
Marking [[done]] since it's not really an ikiwiki bug. --[[Joey]]
|
2009-07-12 22:31:09 +02:00
|
|
|
|
2009-07-13 03:32:24 +02:00
|
|
|
----
|
|
|
|
|
|
2009-07-13 22:28:31 +02:00
|
|
|
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
|
2009-07-13 00:31:35 +02:00
|
|
|
|
2009-07-13 03:32:24 +02:00
|
|
|
> 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]]
|
|
|
|
|
|
2009-07-13 22:28:31 +02:00
|
|
|
>> 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)
|
2009-07-13 03:32:24 +02:00
|
|
|
|
|
|
|
|
> 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]]
|
2009-07-13 22:28:31 +02:00
|
|
|
|
|
|
|
|
>> 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
|
