I wonder if the servlet container is smart enough to notice that if the responding servlet indicates a "gzip" encoding in its header, that it will not try to compress it again as it send s it.
On 11/13/06, Henry Minsky <[EMAIL PROTECTED]> wrote:
It does seem like it is asking for trouble. On 11/13/06, P T Withington <[EMAIL PROTECTED]> wrote: > That doesn't make sense to me. > > Isn't compression for DHTML between the web server and the web > client? If we do compression in our applet, what happens when > someone turns on compression in their container? Double compression, > and lossage? > > I think I can see it made sense to do compression in our applet for > swf because we were talking to a plug-in, not to a web server. > > But, what happens when we deliver a compressed swf via a web server > that is set to do compression? Does the swf get recompressed > (wasting cpu cycles on both the client and the server)? > > On 2006-11-13, at 21:24 EST, David Temkin wrote: > > > In the case that it's a server-deployed app, we should handle this > > ourselves inside of LPS (just as we did for SWF5 apps that were > > gzipped). It's likely that there is code (now defunct) that could > > do this, including caching the compressed app and serving it up > > with the correct headers. > > > > In the case that it's a SOLO app, we should document how to do this > > with the Apache Web Server or similar. > > > > > > On Nov 13, 2006, at 5:56 PM, Benjamin Shine wrote: > > > >> > >> It would be ever so nice if the platform could handle this > >> transparently for us, without relying on application container > >> configuration. > >> > >> On Nov 13, 2006, at 8:42 AM, Henry Minsky wrote: > >> > >>> here's a note I sent in March with a config for tomcat > >>> > >>> > >>> Instructions: > >>> > >>> Restart the Tomcat, and then you can see if it is working by > >>> clearing > >>> the browser cache, and > >>> loading the demo dhtml app. In LiveHTTPHeaders in Firefox you > >>> should > >>> see headers like this > >>> > >>> GET /lps-legals/lps/includes/lfc/lzdataset.js HTTP/1.1 > >>> Host: localhost:8080 > >>> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; > >>> rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 > >>> Accept: */* > >>> 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 > >>> Referer: http://localhost:8080/lps-legals/apps/et/app.lzx? > >>> lzt=dhtml&debug=y&lzr=dhtml > >>> > >>> HTTP/1.x 200 OK > >>> Etag: W/"12841-1141441325754" > >>> Last-Modified: Sat, 04 Mar 2006 03:02:05 GMT > >>> Content-Type: text/javascript > >>> Transfer-Encoding: chunked > >>> Content-Encoding: gzip > >>> Vary: Accept-Encoding > >>> Date: Sat, 04 Mar 2006 22:49:45 GMT > >>> Server: Apache-Coyote/1.1 > >>> > >>> > >>> > >>> > >>> > >>> > >>> server.xml: > >>> > >>> > >>> <Service name="Catalina"> > >>> <Connector acceptCount="100" connectionTimeout="20000" > >>> disableUploadTimeout="true" port="8080" redirectPort="8443" > >>> > >>> compression="on" > >>> compressionMinSize="2048" > >>> noCompressionUserAgents="gozilla, traviata" > >>> compressableMimeType="text/html,text/xml,text/ > >>> javascript,application/x-javascript,application/javascript" > >>>> > >>> </Connector> > >>> <Connector acceptCount="100" disableUploadTimeout="true" > >>> port="8443" scheme="https" secure="true" sslProtocol="TLS" > >>> keystoreFile="conf/lzkeystore" keystorePass="changeit" > >>> compression="on" > >>> compressionMinSize="2048" > >>> noCompressionUserAgents="gozilla, traviata" > >>> compressableMimeType="text/html,text/xml,text/ > >>> javascript,application/x-javascript,application/javascript" > >>> > >>> > >>>> > >>> </Connector> > >>> > >>> > >>> > >>> On 11/13/06, David Temkin <[EMAIL PROTECTED]> wrote: > >>>> When documenting this, we need to discuss, right up front, the > >>>> importance of having gzip compression switched on for the HTTP > >>>> server. There is an enormous size difference between compressed and > >>>> uncompressed, and this isn't an issue for SWF, which has internal > >>>> gzip compression. > >>>> > >>>> When serving from LPS, the Javascript should be automatically > >>>> gzipped. It is, right? > >>>> > >>>> - D. > >>>> > >>>> > >>>> On Nov 13, 2006, at 7:52 AM, Henry Minsky wrote: > >>>> > >>>> > Can anyone tell me what they think is required for DHTML SOLO > >>>> deploy? > >>>> > That is, what > >>>> > auxiliary include files are needed? > >>>> > > >>>> > Since we serve up the LFC and the app as separate files in > >>>> DHTML, the > >>>> > new SOLO wizard will at least have to write out copies of > >>>> static files > >>>> > for these. > >>>> > > >>>> > For reference the current swf solo wizard makes > >>>> > > >>>> > 1) recursive copy of all files in the directory in which the app > >>>> > resides, and also includes > >>>> > 2) An html wrapper file (app.swf.html) > >>>> > > >>>> > 3) these include files > >>>> > filenames.add("lps/includes/embed.js"); > >>>> > filenames.add("lps/includes/h.html"); > >>>> > filenames.add("lps/includes/h.swf"); > >>>> > filenames.add("lps/includes/vbembed.js"); > >>>> > > >>>> > I will make a master list of what needs to be packaged up, and > >>>> make > >>>> > fork a version of the > >>>> > SWF solo deployment tool for DHTML. > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > Henry Minsky > >>>> > Software Architect > >>>> > [EMAIL PROTECTED] > >>>> > >>>> > >>> > >>> > >>> -- > >>> Henry Minsky > >>> Software Architect > >>> [EMAIL PROTECTED] > >> > > > > -- Henry Minsky Software Architect [EMAIL PROTECTED]
-- Henry Minsky Software Architect [EMAIL PROTECTED]
