Bug: Extra empty line added to empty headers

When headers computed by writeHeaderFull (file lib/TWiki.pm, line 519) are the empty string, the line 595:

    $finalHeaders .= "\r\n";             

blindly adds a newline. But, if there are no headers, this results in an extra white line added to the header (I didnt trace the exact mecanism). In the cases where the Content-Length field is computed (edit), this newline is not taken into account in the page length computation (length($tmpl) in edit), thus the sent Content-Length is 2 bytes shorter than the actual contents, making the page end in </htm instead of </html> .

This triggers a bug in IE6 (mozilla, opera, konqueror,... work fine), that makes it behave erractically (displaying various random errors). Users then get the impression that their TWiki edition failed and are quite upset.

Test case

Environment

TWiki version:	Feb 2003
TWiki plugins:
Server OS:	linux
Web server:	Apache 1.3.26, mod_perl
Perl version:	v5.6.1
Client OS:	Windows XP
Web Browser:	IE6

-- ColasNahaboo - 25 Mar 2003

Follow up

Fix record

Juste change the line 595 in lib/TWiki.pm to:

    if ( $finalHeaders) { $finalHeaders .= "\r\n"; } 

Patch attached.

-- ColasNahaboo - 25 Mar 2003

Thanks Colas. Is in TWikiAlphaRelease with a small twist:

    $finalHeaders .= "\r\n" if ( $finalHeaders);

-- PeterThoeny - 26 Mar 2003

This has caused a variety of problems, including UnfinishedCloseHTMLTagUnderModPerl.

-- RichardDonkin - 10 Sep 2003

I think the problem is more insidious than the fix would indicate. I'm also using the Feb. '03 release and having the same problems. It's running on FreeBSD, Apache 1.x, and mod_perl.

In TWiki.pm, near line 534, you see this clause:

    if ($pageType eq 'edit') {

        # Get time now in HTTP header format
        my $lastModifiedString = formatGmTime(time, 'http');

        # Expiry time is set high to avoid any data loss.  Each instance of
        # Edit page has a unique URL with time-string suffix (fix for
        # RefreshEditPage), so this long expiry time simply means that the
        # browser Back button always works.  The next Edit on this page
        # will use another URL and therefore won't use any cached
        # version of this Edit page.
        my $expireHours = 24;
        my $expireSeconds = $expireHours * 60 * 60;

        # Set content length, to enable HTTP/1.1 persistent connections
        # (aka HTTP keepalive), and cache control headers, to ensure edit page
        # is cached until required expiry time.
        $coreHeaders = $query->header(
                            -content_type => $contentType,
                            -content_length => $contentLength,
                            -last_modified => $lastModifiedString,
                            -expires => "+${expireHours}h",
                            -cache_control => "max-age=$expireSeconds",
                         );
    } elsif ($pageType eq 'basic') {
        $coreHeaders = $query->header(
                            -content_type => $contentType,
                         );
    } else {
        writeWarning( "===== invalid page type in TWiki.pm, writeHeaderFull(): $pageType" );
    }

Note that in all cases, $coreHeaders is initialized to something; it should never be empty. Yet on my server, in the debug log, I see that $coreHeaders (and thus $finalHeaders) is empty.

The $query->header() method seems to work fine from the command line:

$ perl -MCGI -e '$a = new CGI; print $a->header("text/xml");'
Content-Type: text/xml; charset=ISO-8859-1

but it seems to be returning blank strings inside my mod_perl environment. Unfortunately, I don't have a backup server where I can test the system without mod_perl.

At any rate, it seems like the proper fix is to figure out why those headers are blank in the first place.

-- KirkStrauser - 18 Nov 2003

Should this patch be applied?

-- MartinCleaver - 08 Apr 2004

I am also (still) running TWikiRelease01Feb2003. I've not noticed any problems, but I'm on a binge to try and fix things up. Should this patch be applied ?

Thanks -- KeithHelfrich