tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TAP5-2201) Serious issue with assets and checksums - different for same file
Date Mon, 04 Nov 2013 22:23:18 GMT

    [ https://issues.apache.org/jira/browse/TAP5-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813352#comment-13813352

Howard M. Lewis Ship commented on TAP5-2201:

There's a lot going on here.

I think at the root of the problem is that Tapestry has to rewrite URLs inside CSS files and
there's some bugs there caused by (would you believe) global variables. It gets confused about
whether it should rewrite relative URLs to use the same scheme (http or https) as the stylesheet.

I think a reasonable solution would be to mark the font extensions (ttf, etc.) as "non-compressable".

It is interesting that the split between uncompressed and GZip compressed URLs (that is the
"/assets" vs. "/assets.gz" folders) was to properly support CDNs, which balked at the same
URL having different contents.

> Serious issue with assets and checksums - different for same file
> -----------------------------------------------------------------
>                 Key: TAP5-2201
>                 URL: https://issues.apache.org/jira/browse/TAP5-2201
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.4
>            Reporter: Magnus Kvalheim
>              Labels: 5.4.22
>         Attachments: bootstrap.server2.css, bootstrap.server3.css, server2.png, server3.png
> Hi everybody.
> Today we've launched a website based on 5.4. We're very exited about the upcoming release(5.4)
and I'll post separately about our experiences (mostly great).
> Post release we've identified a potential serious issue related to assets and their checksums.
> What we see is that a handful of the assets generate different hashes for the same file.
> =Example: bootstrap.css=
> Server 1: 
> /asset.gz/meta/92ffb14a/tapestry5/bootstrap_3_0_0/css/bootstrap.css
> Server 2:
> /asset.gz/meta/5787e482/tapestry5/bootstrap_3_0_0/css/bootstrap.css
> Server 3:
> /asset.gz/meta/f5e7c535/tapestry5/bootstrap_3_0_0/css/bootstrap.css
> Server 3 - restart:
> /asset.gz/meta/219ee41e/tapestry5/bootstrap_3_0_0/css/bootstrap.css
> We also see the same behaviour for the non gzip version of bootstrap.css.
> It is not only for /meta/
> =JCarouselWrapper.css=
> /asset/app/f59da774/mixins/ui/JCarouselWrapper.css
> /asset/app/6ddc92ee/mixins/ui/JCarouselWrapper.css
> As you can see - we're load balanced with app served from several nodes.
> Normally I'd serve these through CloudFront on a cookieless domain (with tapestry as
origin), but it's not possible as load balanced assets could hit 'wrong' server and get the
404 instead.
> So for now they are served through website domain with sticky sessions - and pray that
it don't cause us problems... :)
> All are served with same web container: 
> Apache Tomcat/7.0.39
> JDK 1.7.0_11

This message was sent by Atlassian JIRA

View raw message