blob: b222b297d66bc39ed571e3b66441dc6d9d95a950 (
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
|
I didn't have Time/Duration.pm installed when I clicked RecentChanges. The
perl failed. The CGI outputed the Content-type: text/html and the complete
HTML which included the error in side of the paragraph tags. Maybe a newline
was sent before that Content-type line. The web browser didn't render the HTML
but just showed the source.
> I can't reproduce this, I get a properly formatted error page.
> If you'd like to send me the page, I can try to figure out what
> happened. --[[Joey]]
>> The page is fine. I can reproduce by just putting a typo or error in a
>> plugin. I used tcpdump. When I am missing plugin I get a newline 0a
>> before Content-Type:
0x0030: 0000 0003 0000 0000 0a43 6f6e 7465 6e74 .........Content
>> And with it working, no newline:
0x0030: 0000 0003 0000 0000 436f 6e74 656e 742d ........Content-
>> I am using mini_httpd. I guess I could try another webserver real quick.
>>
>> --JeremyReed
Here's what I see, taking the web server out of the picture:
joey@kodama:~>~/html/ikiwiki.cgi 2>/dev/null |hexdump -C|head -1
00000000 43 6f 6e 74 65 6e 74 2d 74 79 70 65 3a 20 74 65 |Content-type: te|
No spurious 0a. With apache:
0100 75 6e 6b 65 64 0d 0a 43 6f 6e 74 65 6e 74 2d 54 unked..C ontent-T
Here the 0d 0a is a CRLF, and note that it's output by the web server, not
ikiwiki. It's perfectly valid, while a lone 0a, just a linefeed, is not valid
HTTP. Conclusion, this was your web server; it's not uncommon for hacky
little web servers to not use proper CRLF's, and it works _some_ of the time,
depending on how strict the browser is.
I'm calling this [[bugs/done]] --[[Joey]]
|