Hi all,
as far as I can see, the compression of html is real problem.
When in doubts why to use compression, not just when you filling up your
tires, please read:
http://webreference.com/internet/software/servers/http/compression/index
.html
The compression works well for static pages served by http
server. I tried IIS and Apache and both worked well. The problem appears
when client does request to static or dynamic page served by application
server. The problem appears on IIS + WAS 3.5.3 or IIS + Tomcat 3.2.1. I
have also wanted to try the combination Apache+Tomcat 4.x but I was
unable to convince them to work together.
The problem is that you want to send, for instance, string
s="Doubts Anger Disappointment Frustration", but your browser wants to
display something else: "<html><body></body></html>"( IE6.0b does). I
have tested IE5.5, IE6.0b, Netscape 4.73, Mozila - results differ, but
non of them work well. No matter the page is static or dynamic - once
served by application server, the result differs from original. The
problem is *not* in http 1.1 headers. The browser correctly sends
Accept-encoding: gzip and the response header Content-encoding is set to
gzip. I must say here, that yesterday I tried Netscape 6.0 and it seams
to work just fine. So it seams to me like browser problem, related to an
application server.
There are two ways to compress the html content (I know about):
To let the http server automatically compress your pages or to do it
"manually" using GZIPOutputStream. Since our webapp is based mostly on
jsp pages, I tested the next page:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<%@ page language="java" import="java.io.*, java.util.zip.*"
session="true" buffer="1k" contentType="text/html;charset=ISO-8859-2" %>
<%
StringBuffer htmlOut=new StringBuffer("NoN Gzipped Html Content");
String acceptEncoding = request.getHeader("Accept-Encoding");
if(acceptEncoding != null && acceptEncoding.indexOf("gzip") >= 0){
htmlOut=new StringBuffer("Gzipped html content");
response.setHeader("Content-Encoding", "gzip");
GZIPOutputStream gzOut = new
GZIPOutputStream(response.getOutputStream());
gzOut.write(htmlOut.toString().getBytes());
gzOut.close();
response.getOutputStream().close();
}
else
{
response.getWriter().print(htmlOut);
response.getWriter().close();
}
%>
And it works. Even IE can display correct output... but when the user
clicks on refresh button, the output changes to
"<html><body></body><html>". When I set the buffer size to
buffer="none", I get the buggy output.
It seams to me, that application server serves the request by
series of chunks. Apache+mod_gzip collects these chunks, binds them
together, compresses it and sends to client. Nobody (I hope somebody)
knows what IIS does, but it should be the same or similar. It seams to
me that browser receives the compressed stream, does not wait for the
end of the stream and begins the decompression.(I think the
decompression on the fly of the Gzip stream should be possible.) So the
browser will get references to the other parts of the stream. But
because the browser is "smart" and "fast", it displays only the place
for the pics (why not? user can always right-click on the picture ->
show picture (?!!)), it tries to run still not loaded scripts, it simply
changes the still not loaded fonts,....
A one solution is to use only good browsers, for now, only
Netscape 6.x seams to work well. But ... it must be installed before it
can be used, many people are sickly M$ positive, IE html code is not
compatible with Netscape's (every jsp page in our project is designed
for IE), is unable to authentificate itself to ISA server (the big
problem).
Another solution (or just workaround) is still use IE,
"manually" compress jsp pages, disable refresh button, hope it will work
and wait for patch. But... During "manual" compression, ideally one
should just do:
GZIPOutputStream out = new
GZIPOutputStream(response.getOutputStream());
but it does not work, for known reasons. So the other way is to rewrite
the jsp compiler (?!!) and use the new one in application server.
Last solution (I know about) is simply skip the compression.
But...
So, does anybody know:
1.) the other way to compress the html content
2.) anything what can convince IE to act correctly
3.) how to disable refresh button in IE
4.) how to skip "variable already defined" problem in jsp
5.) where can I get sources of free jsp compiler
6.) how to learn Netscape use authentification against ISA server.
We are trying to post IE bug to M$, but it can be difficult since the
application servers are not M$ products so any comments, ideas or
explanations are welcomed.
Thank you for reading, I hope it will save few days and nerves.
Maros.
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
