From nobody Thu Apr 3 14:38:08 1997 Received: (from nobody@localhost) by taz.hyperreal.com (8.8.4/8.8.4) id OAA15252; Thu, 3 Apr 1997 14:38:08 -0800 (PST) Message-Id: <199704032238.OAA15252@taz.hyperreal.com> Date: Thu, 3 Apr 1997 14:38:08 -0800 (PST) From: Christian Saether Reply-To: christians@asymetrix.com To: apbugs Subject: JDK 1.02 HTTP libraries dislike something X-Send-Pr-Version: 3.2 >Number: 311 >Category: protocol >Synopsis: JDK 1.02 HTTP libraries dislike something >Confidential: no >Severity: critical >Priority: medium >Responsible: apache >State: closed >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Thu Apr 3 14:40:01 1997 >Last-Modified: Thu Jan 22 07:44:35 PST 1998 >Originator: christians@asymetrix.com >Organization: >Release: N/A >Environment: NT 3.51, sp5, Pentium, SuperCede runtime client >Description: One of our (SuperCede) customers reported a problem using the URLConnection class to read the HTML off your page. In particular, the header shows up in the input stream, instead of being parsed. I've only been able to determine that some decision is being made in the jdk1.02 sun.net.www.* class libraries, which we distribute. We do not license the Sun VM, however, so I do not have access to source. Our customer reports this is a problem with the Sun JDK1.02 also. This may be an HTTP/1.1 protocol issue - I hope you can enlighten me or make this problem go away! >How-To-Repeat: Here's a small program which when run using SuperCede, and presumably JDK1.02, will show unexpected header information being read: import java.io.*; import java.net.*; public class Source1 { public static void main (String args[]) { try { URL turl = new URL("http://www.apache.org"); System.out.println( turl.toString() ); URLConnection curl = turl.openConnection(); System.out.println( curl ); InputStream ins = curl.getInputStream(); System.out.println( ins ); byte[] buff = new byte[10000]; int bread = ins.read(buff); System.out.println("\nread "+bread+"\n"); if ( bread > 0 ) { String str = new String(buff,0,0,bread); System.out.println(str); } ins.close(); } catch (Exception ex) { System.out.println(ex); } } } >Fix: Nope. Thanks for your time. Apologies if this is well understood - I tried searching your problem database for "compatibility" and "1.02" but turned up nothing. %0 >Audit-Trail: State-Changed-From-To: open-closed State-Changed-By: coar@decus.org State-Changed-When: Thu Apr 3 15:15:15 PST 1997 State-Changed-Why: This is a known problem with the JDK 1.0.2 release. It does not understand the HTTP/1.1 header information. Apache is emitting the correct headers for the HTTP/1.1 protocol, but the JDK hasn't caught up yet. (At least it hadn't as of 1.0.2.) Please see closed report #285 in the Apache bug database (http://www.apache.org/bugdb.cgi) for a workaround. State-Changed-From-To: closed-analyzed State-Changed-By: coar@decus.org State-Changed-When: Sat Apr 5 06:38:14 PST 1997 State-Changed-Why: Re-opening until verified. State-Changed-From-To: analyzed-suspended State-Changed-By: coar State-Changed-When: Tue May 6 07:58:35 PDT 1997 State-Changed-Why: This problem has been reported to Sun's JavaSoft unit as a bug in the JDK 1.0.2 and 1.1 libraries. No feedback from them yet. In the meantime, Apache servers can add the following lines to their configuration to WORK AROUND this issue: BrowserMatch HotJava/1. force-response-1.0 BrowserMatch Java1. force-response-1.0 This will be noted in the FAQ as well. State-Changed-From-To: suspended-closed State-Changed-By: coar State-Changed-When: Wed May 14 14:08:08 PDT 1997 State-Changed-Why: Sun has acknowledged that this was a bug in the JDK 1.0.2 libraries. They report that it is fixed in the 1.1 class libraries (I have not yet verified this personally). The workaround is to add a BrowserMatch directive to the Apache configuration; the solution is to rebuild/configure your applications to use the JDK 1.1 libraries. See the FAQ () for the details of the BrowserMatch syntax. Release-Changed-From-To: your Web site on 4/3/97-N/A Release-Changed-By: coar Release-Changed-When: Thu Jan 22 07:44:34 PST 1998 >Unformatted: