ikiwiki (3.20130711) unstable; urgency=low
[ikiwiki.git] / doc / bugs / CGI_problem_with_some_webservers.mdwn
1 The "ikwiki.cgi?page=index&do=edit" function has a problem
2 when running with [[!debpkg thttpd]] or [[!debpkg mini-httpd]]:
3 for some reason the headers ikiwiki outputs are transmitted
4 as the page content. Surprisingly, the "do=prefs" function
5 works as expected.
6
7 Here is what it looks like in iceweasel:
8
9     Set-Cookie: ikiwiki_session_apnkit=99dad8d796bc6c819523649ef25ea447; path=/
10     Date: Tue, 14 Aug 2007 17:16:32 GMT
11     Content-Type: text/html; charset=utf-8
12     
13     <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
14      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
15     <html>
16     (...)
17
18 Ikiwiki runs fine with [[!debpkg boa]].
19
20 --[[JeremieKoenig]]
21
22 It doesn't work for signin either.
23 What is the reason for these "header => 1" in FormBuilder initialisations?
24 Why do they appear two times with conflicting values in the very same hashes?
25
26 --[[JeremieKoenig]]
27
28 > Clearly those duplicate header settings are a mistake. But in all cases, the
29 > `header => 0` came second, so it _should_ override the other value and
30 > can't be causing this problem. (cgi_signin only sets it to 0, too).
31
32 > What version of formbuilder are you using? If you run ikiwiki.cgi at the
33 > command line, do you actually see duplicate headers? I don't:
34
35         joey@kodama:~/html>REQUEST_METHOD=GET QUERY_STRING="page=index&do=edit" ./ikiwiki.cgi
36         Set-Cookie: ikiwiki_session_joey=41a847ac9c31574c1e8f5c6081c74d12; path=/
37         Date: Tue, 14 Aug 2007 18:04:06 GMT
38         Content-Type: text/html; charset=utf-8
39         
40         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
41
42 > Do thttpd and mini-httpd perhaps not realize that Set-Cookis is the start of
43 > the headers? --[[Joey]]
44
45 >> Thanks for your help: I think I found the problem!
46 >> Ikiwiki outputs (in my case) the following
47 >> error message on stderr, followed by an empty line:
48
49     /srv/ikiwiki/wc/index.mdwn:  (Not a versioned resource)
50
51 >> Probably thttpd and mini-httpd read stderr as well as stdout, while apache
52 >> and boa don't. When using a shell-script wrapper as the CGI,
53 >> which redirects ikiwiki's error output to /dev/null, it works better.
54
55 >> The edit still fails to commit, because in my wiki, index.mdwn is
56 >> pulled from the base wiki and somehow ikiwiki wants to change it
57 >> rather that create it.
58
59 >> --[[JeremieKoenig]]
60
61 >>> If thttpd and mini-httpd interpret CGI's stderr as stdout, then
62 >>> they're not properly following the CGI spec, and will break with tons
63 >>> of cgi scripts besides ikiwiki. And of course there are many many cases
64 >>> where ikiwiki might output to stderr, and that's the right thing to do.
65 >>> So I don't see any way to address this in ikiwiki. --[[Joey]]
66
67 >>>> (reported as [[!debbug 437927]] and [[!debbug 437932]]) --[[JeremieKoenig]]
68
69 Marking [[done]] since it's not really an ikiwiki bug. --[[Joey]]
70
71 ----
72
73 I'm using boa and getting some odd behaviour if I don't set the `umask`
74 option in the config file.  Editing a page through the web interface and
75 hitting "Save Page" regenerates the `index.html` file with no world-read
76 permissions.  As a result, the server serves a "403 - Forbidden" error page
77 instead of the page I was expecting to return to.
78
79 There are only two ways I found to work around this: adding a `umask 022`
80 option to the config file, or re-compiling the wiki from the command line
81 using `ikiwiki --setup`.  Setting up a git back-end and re-running `ikiwiki
82 --setup` from inside a hook had no effect; it needed to be at the terminal.
83 --Paul
84
85 > Since others seem to have gotten ikiwiki working with boa, 
86 > I'm guessing that this is not a generic problem with boa, but that
87 > your boa was started from a shell that had an unusual umask and inherited
88 > that. --[[Joey]] 
89
90 >> That's right; once I'd worked out what was wrong, it was clear that any
91 >> webserver should have been refusing to serve the page.  I agree about the
92 >> inherited umask; I hadn't expected that.  Even if it's unusual, though, it
93 >> probably won't be uncommon - this was a stock Ubuntu 9.04 install.  --Paul
94
95 (I'm new to wiki etiquette - would it be more polite to leave these details
96 on the wiki, or to remove them and only leave a short summary?  Thanks.
97 --Paul)
98
99 > Well, I just try to keep things understandable and clear, whether than
100 > means deleting bad old data or not. That said, this page is a bug report,
101 > that was already closed. It's generally better to open a new bug report
102 > rather than edit an old closed one. --[[Joey]] 
103                                       
104 >> Thanks for the feedback, I've tidied up my comment accordingly.  I see
105 >> your point about the bug; sorry for cluttering the page up.  I doubt it's
106 >> worth opening a new page at this stage, but will do so if there's a next
107 >> time.  The solution seems worth leaving, though, in case anyone else in my
108 >> situation picks it up.  --Paul