Then that should definitely be the default. On Mon, Nov 23, 2009 at 1:47 AM, Ben Gidley <b...@gidley.co.uk> wrote: > I have also seen this locally so I don't believe it is proxy - I just add > flash to non-gzippable types. > > > > Ben Gidley > > www.gidley.co.uk > b...@gidley.co.uk > > > On Sun, Nov 22, 2009 at 12:16 PM, Howard Lewis Ship <hls...@gmail.com>wrote: > >> On Fri, Nov 20, 2009 at 3:18 PM, Taylor Mathewson >> <taylor.mathew...@gmail.com> wrote: >> > Hi all, >> > >> > I found a possible problem and a workaround, and I just want to put it up >> > here in case anyone else encounters a similar problem. >> > >> > I have a Flex3 element embedded in a page. It would load, but it >> wouldn't >> > run. We stripped it down to a very simple app (hello world), but it >> still >> > wouldn't run. >> > >> > Right clicking on the flash element showed the problem: the "Play" item >> was >> > unchecked on the flash player context menu. Selecting it would run the >> flex >> > piece as expected, but reloading the page, it would again not play. >> > >> > Accessing the swf directly yielded strange results. >> > >> > Going through a standard path (e.g. >> > http://localhost:8080/appName/swf/myFlex.swf) worked fine but going >> through >> > Tapestry's context (e.g. >> > http://localhost:8080/appName/assets/ctx/631103cab3b12068/swf/myFlex.swf >> ) >> > would load the component but not play it. >> > >> > This offers with one option; link to all flash components directly. >> > However, the tapestry context urls present a nice solution to avoiding >> > cached older versions of flash elements, without forcing a client to >> > re-download on every view. >> > >> > The other solution I found was to disable GZIP on >> > application/x-shockwave-flash by contributing that content type to the >> > responsecompressionanalyzer >> >> Could a server in between Tapestry and the client be re-gzipping or >> otherwise corrupting the bytestream? >> >> In any case, I suspect adding flash as a non-compressable type would >> be a good idea; a JIRA issue would be appreciated. >> >> > >> > I'm not sure why this happens, and it seems not to happen with >> > flash-authored pieces, as opposed to flex-authored, even when they are >> > published with the same player version etc... and why it happens only in >> the >> > tapestry context path (according to LiveHTTP, both had gzip compression, >> but >> > the tapestry context had a content-length about 25 bytes higher). >> > >> > Just hoping to save others the couple hours of "wtf" I just went through. >> > >> > Thanks, >> > Taylor >> > >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> >
-- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
