In any event, this is too risky to go in to the upcoming release.
On 11/13/06, Henry Minsky <[EMAIL PROTECTED]> wrote:
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]
-- Henry Minsky Software Architect [EMAIL PROTECTED]
