ikiwiki (3.20130711) unstable; urgency=low
[ikiwiki.git] / doc / bugs / Running_on_an_alternative_port_fails.mdwn
1 Can't appear to get 'wiki' functions (i.e. editing) running when ikiwiki is running on a port other than the default (port 80).  Somewhere in the processing it considers the base URL to exclude the port number and the websever throws back an error finding the page.
2
3 For example if you run on 'http://my.gear.xxx:8080/' then after clicking login (using default password auth) it will process and try to redirect you to 'http://my.gear.xxx/cgi-bin/ikiwiki.cgi'.  I'm assuming that somewhere we've used the 'path' and the 'host' and dropped the remainder.  I can figure out where this is yet but I'll post back if I get lucky.
4
5  -- fergus
6
7 NB: both the 'url' and the 'cgiurl' include the port and removing the port element provides the expected functionality.
8
9 ---
10
11 > I tried to reproduce this by making my laptop's web server use port
12 > 8080. Set up ikiwiki to use that in cgiurl and url, and had
13 > no problem with either openid or password auth login.
14
15 > Ikiwiki has had some changes in this area in the past year; you don't say
16 > what version you were using. It could also be a problem with your web
17 > server, conceviably, if didn't correctly communicate the port to the cgi
18 > program. --[[Joey]]
19
20 ---
21
22 >> I did think of that so threw a 'printenv' script to check the port was arriving 
23 right.
24
25 >>>     SERVER_PORT=8181  
26 >>>     HTTP_HOST=zippy0.ie0.cobbled.net  
27
28 [ ... ]
29
30 >>>> In apache, `HTTP_HOST` includes the port. This is not part of the CGI
31 >>>> spec it seems, but perl's `CGI` module seems to rely on it,
32 >>>> in `virtual_port`:
33
34 >>>>>     my $vh = $self->http('x_forwarded_host') || $self->http('host');
35 >>>>>     my $protocol = $self->protocol;
36 >>>>>     if ($vh) {
37 >>>>>        return ($vh =~ /:(\d+)$/)[0] || ($protocol eq 'https' ? 443 : 80);
38
39 >>>> The `CGI` module only looks at `SERVER_PORT` when there's no
40 >>>> `HTTP_HOST`. So this is either a bug in perl's CGI or thttpd.
41 >>>> --[[Joey]]
42
43 [ ... ]
44
45 ---
46
47 >>>>> This is interesting.  If HTTP_HOST is wrong then
48
49 >>>>> 0. the client header must be wrong (i.e. not including the PORT)
50 >>>>> 0. `perl`'s doing something bad[tm] (or at least lazy)
51 >>>>> 0. `apache` is adding it
52 >>>>> 0. `thttpd` is stripping it
53
54 >>>>> Quick hack shows that `thttpd` must be stripping the port
55 number from the `Host:` header.  That can be fixed.
56
57 >>>>> Thanks for the assist. -- fergus
58
59 ---
60
61 Patch for `thttpd-2.25b` for posterity and completeness
62
63 [[!format patch """
64
65 diff --git a/libhttpd.c b/libhttpd.c
66 index 73689be..039b7e3 100644
67 --- a/libhttpd.c
68 +++ b/libhttpd.c
69 @@ -2074,9 +2074,6 @@ httpd_parse_request( httpd_conn* hc )
70                 cp = &buf[5];
71                 cp += strspn( cp, " \t" );
72                 hc->hdrhost = cp;
73 -               cp = strchr( hc->hdrhost, ':' );
74 -               if ( cp != (char*) 0 )
75 -                   *cp = '\0';
76                 if ( strchr( hc->hdrhost, '/' ) != (char*) 0 || hc->hdrhost[0] == '.' )
77                     {
78                     httpd_send_err( hc, 400, httpd_err400title, "", httpd_err400form, "" );
79
80 """]]
81
82 -- fergus
83
84 ---
85
86 I've gone ahead and filed a bug on CGI.pm too:
87 <https://rt.cpan.org/Ticket/Display.html?id=72678> --[[Joey]] 
88
89 ---
90
91 That'll be an interesting discussion as I'd suggest that HTTP_ headers are defined in the CGI specification as client headers and thus what `thttpd` is doing is wrong (i.e. mangling the client's own representation).  Whether a CGI client should trust HTTP_ header over the server is probably already settled by convention.
92
93 -- fergus