aboutsummaryrefslogtreecommitdiff
path: root/doc/bugs/CGI_problem_with_some_webservers.mdwn
blob: 2240f5dc3b6b100d280c57f2576bff113f7c975a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
The "ikwiki.cgi?page=index&do=edit" function has a problem
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.

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>
    (...)

Ikiwiki runs fine with [[!debpkg boa]].

--[[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
	
	<!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]]

>> 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 getting some odd behaviour with boa.  When I edit a page and click "Save
Page", the URL I get taken to produces a 403 - Forbidden error until I recompile
the wiki.  For example, after editing the root page of the wiki it brings me back to
`http://localhost/~pdw/iki/?updated`, and I see a 403 error message.  Then, if
I open up a terminal and type `ikiwiki --setup ikiwiki.setup`, and then go back
to the browser and hit Ctrl-R, the page displays correctly, with the same URL
that gave an error a moment ago.  This is with boa 0.94.14rc21-3 and Firefox
3.0.11 on Ubuntu 9.04.  I get the feeling I'm doing something wrong somewhere;
any suggestions where to start looking?  This is a very basic setup, so feel
free to ask. --Paul