]> git.ipfire.org Git - thirdparty/apache/httpd.git/commitdiff
Corrected FAQ about Java to reflect the latest edition of
authorKen Coar <coar@apache.org>
Wed, 28 May 1997 19:02:13 +0000 (19:02 +0000)
committerKen Coar <coar@apache.org>
Wed, 28 May 1997 19:02:13 +0000 (19:02 +0000)
reality as we know it.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@78172 13f79535-47bb-0310-9956-ffa450edef68

docs/manual/misc/FAQ.html

index 99076baade98afde70e279b20db01600d868b1f1..2705f17f91048ffabf4bafb612063e869a611607 100644 (file)
@@ -8,7 +8,7 @@
   <!--#include virtual="header.html" -->
   <H1>Apache Server Frequently Asked Questions</H1>
   <P>
-  $Revision: 1.59 $ ($Date: 1997/05/19 21:10:22 $)
+  $Revision: 1.60 $ ($Date: 1997/05/28 19:02:13 $)
   </P>
   <P>
   The latest version of this FAQ is always available from the main
    <LI><A HREF="#addlog">How do I add browsers and referrers to my
     logs?</A>
    </LI>
-   <LI><A HREF="#jdk1.x">Why do Java applets and applications not work
-    with documents on my Apache server?</A>
-   </LI>
   </OL>
  </LI>
 </UL>
   As of version 1.2, Apache is an HTTP/1.1 (HyperText Transfer Protocol
   version 1.1) server.  This fact is reflected in the protocol version
   that's included in the response headers sent to a client when
-  processing a request.  Unfortunately, the URL methods (URLConnection
-  and friends) in the Java Development Kit (JDK) versions 1.0.2 through
-  1.1.1 expect to see the version string &quot;HTTP/1.0&quot; and do not
-  correctly interpret the &quot;HTTP/1.1&quot; value Apache is sending
-  (this part of the response is a declaration of what the server can do
-  rather than a declaration of the dialect of the response).  The result
+  processing a request.  Unfortunately, low-level Web access classes
+  included in the Java Development Kit (JDK) version 1.0.2 expect to see
+  the version string &quot;HTTP/1.0&quot; and do not correctly interpret
+  the &quot;HTTP/1.1&quot; value Apache is sending (this part of the
+  response is a declaration of what the server can do rather than a
+  declaration of the dialect of the response).  The result
   is that the JDK methods do not correctly parse the headers, and
   include them with the document content by mistake.
   </P>
   <P>
-  This is definitely a bug in the JDK, but it's unclear when (or
-  whether) it will be fixed.  In the meantime, a workaround is to tell
+  This is definitely a bug in the JDK 1.0.2 foundation classes from Sun,
+  and it has been fixed in version 1.1.  However, the classes in
+  question are part of the virtual machine environment, which means
+  they're part of the Web browser (if Java-enabled) or the Java
+  environment on the client system - so even if you develop
+  <EM>your</EM> classes with a recent JDK, the eventual users might
+  encounter the problem.
+  The classes involved are replaceable by vendors implementing the
+  Java virtual machine environment, and so even those that are based
+  upon the 1.0.2 version may not have this problem.
+  </P>
+  <P>
+  In the meantime, a workaround is to tell
   Apache to &quot;fake&quot; an HTTP/1.0 response to requests that come
   from the JDK methods; this can be done by including a line such as the
   following in your server configuration files:
   </P>
   <P>
   <DL>
-   <DD><CODE>BrowserMatch HotJava/1.0 force-response-1.0</CODE>
+   <DD><CODE>BrowserMatch Java/1.0 force-response-1.0</CODE>
    </DD>
   </DL>
   </P>