[jira] [Commented] (TAP5-2201) Serious issue with assets and checksums - different for same file

["Howard M. Lewis Ship (JIRA)" <ji...@apache.org>]

    [ 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
(v6.1#6144)