X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/d4101ad64f801f862cceab51f91a2a66e51b73d8..03881f6b1af9c9ec8393ed5842b87778c346dae2:/doc/bugs/Running_on_an_alternative_port_fails.mdwn diff --git a/doc/bugs/Running_on_an_alternative_port_fails.mdwn b/doc/bugs/Running_on_an_alternative_port_fails.mdwn index ca835cb59..942700ba3 100644 --- a/doc/bugs/Running_on_an_alternative_port_fails.mdwn +++ b/doc/bugs/Running_on_an_alternative_port_fails.mdwn @@ -24,27 +24,70 @@ right. >>> SERVER_PORT=8181 >>> HTTP_HOST=zippy0.ie0.cobbled.net ->>> HTTP_ACCEPT_LANGUAGE=en-ie, en ->>> PATH=/usr/local/bin:/usr/ucb:/bin:/usr/bin ->>> SCRIPT_NAME=/cgi-bin/printenv.sh ->>> HTTP_USER_AGENT=Mozilla/5.0 (X11; U; Linux i686; en-ie) AppleWebKit/531.2+ (KHTML, like Gecko) Version/5.0 Safari/531.2+ Ubuntu/10.10 () Epiphany/2.30.2 ->>> PWD=/home/http1/www/cgi-bin ->>> REQUEST_METHOD=GET ->>> SERVER_SOFTWARE=thttpd ->>> SERVER_NAME=zippy0 ->>> SERVER_PROTOCOL=HTTP/1.1 ->>> HTTP_ACCEPT_ENCODING=gzip ->>> GATEWAY_INTERFACE=CGI/1.1 ->>> CGI_PATTERN=cgi-bin/* ->>> HTTP_COOKIE=ikiwiki_session_c%5E2%3Fsupport%3Dtrue=bdf13df0460966a607ba497967ea5ff4 ->>> REMOTE_ADDR=10.0.0.1 ->>> HTTP_ACCEPT=application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 - ->>Seems to be. Using version from packaging system; - ->>> ikiwiki-3.20110905 - ->> which I'd guess is from Apr last year. Will look for updates and post back if still -wrong. ->> Cheers ->> -- fergus + +[ ... ] + +>>>> In apache, `HTTP_HOST` includes the port. This is not part of the CGI +>>>> spec it seems, but perl's `CGI` module seems to rely on it, +>>>> in `virtual_port`: + +>>>>> my $vh = $self->http('x_forwarded_host') || $self->http('host'); +>>>>> my $protocol = $self->protocol; +>>>>> if ($vh) { +>>>>> return ($vh =~ /:(\d+)$/)[0] || ($protocol eq 'https' ? 443 : 80); + +>>>> The `CGI` module only looks at `SERVER_PORT` when there's no +>>>> `HTTP_HOST`. So this is either a bug in perl's CGI or thttpd. +>>>> --[[Joey]] + +[ ... ] + +--- + +>>>>> This is interesting. If HTTP_HOST is wrong then + +>>>>> 0. the client header must be wrong (i.e. not including the PORT) +>>>>> 0. `perl`'s doing something bad[tm] (or at least lazy) +>>>>> 0. `apache` is adding it +>>>>> 0. `thttpd` is stripping it + +>>>>> Quick hack shows that `thttpd` must be stripping the port +number from the `Host:` header. That can be fixed. + +>>>>> Thanks for the assist. -- fergus + +--- + +Patch for `thttpd-2.25b` for posterity and completeness + +[[!format patch """ + +diff --git a/libhttpd.c b/libhttpd.c +index 73689be..039b7e3 100644 +--- a/libhttpd.c ++++ b/libhttpd.c +@@ -2074,9 +2074,6 @@ httpd_parse_request( httpd_conn* hc ) + cp = &buf[5]; + cp += strspn( cp, " \t" ); + hc->hdrhost = cp; +- cp = strchr( hc->hdrhost, ':' ); +- if ( cp != (char*) 0 ) +- *cp = '\0'; + if ( strchr( hc->hdrhost, '/' ) != (char*) 0 || hc->hdrhost[0] == '.' ) + { + httpd_send_err( hc, 400, httpd_err400title, "", httpd_err400form, "" ); + +"""]] + +-- fergus + +--- + +I've gone ahead and filed a bug on CGI.pm too: + --[[Joey]] + +--- + +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. + +-- fergus