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 > >
