HTTPS implementation doesn't provide header fields

Name: mt13159 Date: 02/21/2001


The HTTPS implementation in Java plug-in 1.3 uses the browser API to make HTTPS connections. But it handles HTTP connections itself. This means that there are large differences in the behavior of HTTP and HTTPS connections. The biggest problem is that in Netscape, header fields are not available on HTTPS URLConnection objects. This makes it impossible to do any caching, because the last-modified and expiration headers on not obtainable (this is even a problem for the Java plug-in's own JAR caching implementation, which needs the CACHE_VERSION property to work around this bug). This also breaks existing code we have that sends data packets through HTTP, because that code relies heavily on the content-length header to get the size of the data. It also makes it difficult to get cookie information (which is bug 4260458), or get any other custom headers which the server is trying to send. There are other problems as well, such as browser dialogs popping up when an applet is making connections. The browser status bar and progress bar also update every connection, which is not desirable in some cases, such as an applet which is constantly sending data back and forth with the server.
Really, what is needed is a non-browser-based HTTPS implementation. That is, an implementation which uses JSSE to make the SSL connection to the web server. Such an implementation could provide the same functionality as the current HTTP code, and in fact could reuse much of that code to ensure similarity. The only difficult implementation issue would probably be certificate handling, since you could no longer rely on the browser to do this.
(Review ID: 117334)
======================================================================