on 2009-03-13 22:49
on 2009-03-14 16:04
My guess is that the Java applet isn't telling the server that it can accept compressed content when it makes the requests to nginx. Try configuring the applet to tell the server to send gzipped content. Note that it's possible that Java applets may not be able to handle compressed content at all, in which case it's a good thing that nginx is not making that assumption. You should be able to watch the requests with Firebug in Firefox to see the Accept-Encoding header. If you can't see the Java applet requests with Firebug (or another Firefox headers extension) you can use Ethereal or a command-line tool on the client or server. See section 14.3 of the W3's HTTP/1.1 Header Field Definitions page for more info: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
on 2009-03-14 17:50
On Sat, Mar 14, 2009 at 02:11:38AM +0530, hirantha wrote: > receiving data without any issue. But the problem is those text data > won't get compressed though text, images etc loaded to the browser get > compressed. I can compress data off the applet but once it send it to > java applet, won't get compressed. It seems that java applet does not send the "Accept-Encoding: gzip" request header. BTW why do you compress image/gif image/jpeg image/png ? This is just waste of CPU time.
on 2009-03-14 22:38
Thanks guys for the replies.. Igor S. wrote: >> end users. Nginx is act as a reverse-proxy for back-end web servers; >> once the java applet loaded on the FireFox or IE browser it keep >> receiving data without any issue. But the problem is those text data >> won't get compressed though text, images etc loaded to the browser get >> compressed. I can compress data off the applet but once it send it to >> java applet, won't get compressed. > > It seems that java applet does not send the "Accept-Encoding: gzip" > request header. I ran Wireshark to analyze the data on java applet and firefox browser to check what type of header request they send. Here are my findings. From browser: GET /mbr/ds.aspx?SID=1F5AAWQWQWSA1 HTTP/1.1 Host: data.example.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/2009030503 Fedora/3.0.7-1.fc10 Firefox/3.0.7 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive From Java applet loaded from Firefox: GET /sabb/GetUserParams.aspx?Y=BC672 HTTP/1.1 User-Agent: Java(tm) 2 SDK, Standard Edition v1.6.0_0 Java/1.6.0_0 Host: data.example.com Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive I think java applet don't sends Accept-Encoding header to the server; and this should be the problem. I am not a java expert and the new question, is this possible with a java applet set Accept-Encoding request header...? > > BTW why do you compress image/gif image/jpeg image/png ? > This is just waste of CPU time. Yes, I have to avoid them, my concern is huge text data. Any advice on the new question is really appreciated. Regards Hirantha
on 2009-03-14 23:27
Depends on how the applet is written, I'd guess. Not sure though. However, if compression is very important and accepting gzipped content is not possible with an applet, you could gzip the files beforehand so that the files that are served are gzipped already (even though there's no Accept-Encoding header). This would of course require that the applet decompress the text before processing, but at least you'd cut down on your network traffic...
on 2009-03-15 20:01
Thanks guys, It is working as expected...! And thanks to nginx guys, this is amazing service. Regards Hirantha