DO NOT REPLY [Bug 4259] New: - SSI prosessing loses content-type information

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4259>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4259

SSI prosessing loses content-type information

           Summary: SSI prosessing loses content-type information
           Product: Tomcat 4
           Version: 4.0 Final
          Platform: Sun
        OS/Version: Linux
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: rami.hanninen@davisor.com


Tomcat Server Side Include servlet seem to drop content-type information from
the responses it gives. In other words, calls to URLConnection.getContentType()
seem to return 'null' for SSI expanded documents. If SSI is deactivated, the
same operation works fine.

I tested the problem with the following simple program. The program outputs the
content type and content of a document downloaded from given URL address. For
SSI expanded files HTML files, the content type was always 'null', for others,
'text/html'. The content itself downloaded always fine.

package tmp;

import java.net.*;
import java.io.*;

public class URLReader
{
    public static void main(String[] args) throws Exception {
        URL url= new URL(args[0]);
        URLConnection yc = url.openConnection();
        System.out.println("ContentType: " + yc.getContentType());
        BufferedReader in = new BufferedReader(
                                new InputStreamReader(
                                yc.getInputStream()));
        String inputLine;

        while ((inputLine = in.readLine()) != null)
            System.out.println(inputLine);
        in.close();
    }
}