Name: krC82822 Date: 08/06/2001


NT and Linux:
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)

[This is a re-submission. The initial reviewer had thought this problem might
have been fixed for 1.3.1.]

I suspect the problem is in JSSE, not in Java's runtime proper. Both Linux and
Windows 2k versions are showing the bug. Hence, I'm going to submit it through
JSSE, generic problem.

1. I'm submitting this on behalf of my employer, XXXXXXXXXXX.
However, the problem is general enough that it could happen to anybody; I even
suspect this is a duplicate. (It still needs to be fixed, of course, by one of
the principals.)

2. For the purposes of this bug report, call the originating machine
StartHere.somewhere.com, the proxy machine Proxy.somewhere.com, and the
destination machine OverThere.somewhere.else.com. Proxy runs version 2 (?) of
Microsoft Proxy Server (MS has assured us that this has been fixed in their
newer ISA product). OverThere understands port 443 (https) TLS/SSL
connections. (Apologies in advance to whoever owns somewhere.com or else.com.)

3. I'm not sure whether to file this under JDK (J2SE) or JSSE, as the problem
disappears if 'http' is used instead of 'https'.

4. The Java code is extremely simple. I could use the -Dhttps.proxyHost form
during invocation (that's what our application does), but the code fragment
below should make things very clear. It of course runs on StartHere. Under
ideal conditions it spits out the page opened on standard output.

--- URLViewer.java ---
import java.io.*;
import java.net.*;
public class URLViewer
{
  public static void main(String[] args)
  {
    try
    {
      System.setProperty
("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol");
      System.setProperty("http.proxyHost", "Proxy.somewhere.com");
      System.setProperty("http.proxyPort", "80");
      System.setProperty("https.proxyHost", "Proxy.somewhere.com");
      System.setProperty("https.proxyPort", "80");
      URL u = new URL("https://OverThere.somewhere.else.com/index.html");
      URLConnection uc = u.openConnection();
      Reader r = new BufferedReader(new InputStreamReader(uc.getInputStream()));
      int c;
      while((c = r.read()) >= 0)
        System.out.print((char) c); // yes, this is slow
    }
    catch(Exception ex) { ex.printStackTrace(System.err); }
  }
}
--- end ---

4. Sniffing reveals that the CONNECT request (RFC2616:9.9) issued to the proxy
elicits the response

HTTP/1.0 200 Connection established

Note the extra space between the status code and the message, in apparent
violation of RFC2616:6.1 -- however, RFC2616:19.3 specifically states that
applications should be tolerant of this sort of thing.

On most networks, this will either result in an invisible failure (the JDK will
attempt to directly connect), or completely block the request (on one of our
customer sites, that's exactly what happened; we eventually moved the
application to the demilitarized zone, bypassing the proxy -- this is obviously
not an ideal solution). A blocked request will throw an exception, which I
can't reproduce here (our network doesn't block).

I would submit that JDK -- or possibly JSSE -- should be more tolerant of that
extra space. Hence, this bug report.

(There is another bug report somewhere that showed a similar problem, complete
with two spaces, with a proxy authorization failure, but darned if I can find
it now.)

If you don't have it already http://www.faqs.org/rfcs/rfc2616.html is probably
as good a place as any.

5. This does not appear to be platform-specific.

6. -Xint did nothing; neither did -Xfuture.
(Review ID: 126846)
======================================================================