20

I have just noticed something very worrying with the represented path to static resource files in Visualforce pages in Summer '16 boxes (sandbox and dev pre-release checked).

It seems that for some file extensions the path includes a query string appended with an orgId param.

For example I have a VF page like this;

{!URLFOR($Resource.ToddStaticTest, 'static-test/eot.eot')}
{!URLFOR($Resource.ToddStaticTest, 'static-test/woff.woff')}
{!URLFOR($Resource.ToddStaticTest, 'static-test/ttf.ttf')}
{!URLFOR($Resource.ToddStaticTest, 'static-test/svg.svg')}

And the output of the page is something like this.

/resource/1464812981000/ToddStaticTest/static-test/eot.eot?orgId=00DB00000004GGI
/resource/1464812981000/ToddStaticTest/static-test/woff.woff?orgId=00DB00000004GGI
/resource/1464812981000/ToddStaticTest/static-test/ttf.ttf?orgId=00DB00000004GGI
/resource/1464812981000/ToddStaticTest/static-test/svg.svg?orgId=00DB00000004GGI

Note, this does not happen if I have an asset with the extension capitalised. It does also not happen to .png, .css, .html files. Spring '16 (and earlier) boxes did also NOT show this behaviour.

This causes serious app-breaking issues for anyone on iOS (and Desktop Safari, I think) when they're also using a cache mechanism such as appcache.

I can't find any mention of anything like this in the release notes, but would love to know;

  • How can I turn this off?
  • Which extensions are affected (I have only done limited testing, thus far)?
  • What reason is there for this happening?

UPDATE: This behaviour seems to be related to this partner alert and was put in place for files relating to those needed for web fonts. I'm not sure exactly why. It seems a little bit dirty as SVGs can be used for all sorts, not just fonts.

In my case I was able to get around this by giving my assets CAPITAL extensions (such as .SVG).

I am also in the process of raising a case as it seems that non-managed-packaged assets should also be handled as per the partner alert... and also that non-font-face .svg references would also be missed and lead to broken references.

4
  • Just curious, is this issue causing you any specific problems? Can you possibly outline those consequences a bit?
    – Adrian Larson
    Commented Jun 1, 2016 at 23:29
  • 3
    @AdrianLarson I think one of the problems is with appcache and query string parameters. I gather from that link that you need to identify URLs to cache, including the parameters. In a managed package that URL will change, so it becomes harder to identify what to cache. Especially if not all links get the orgId param appended. At least that is my take on it. I could be way off. Commented Jun 2, 2016 at 0:47
  • 1
    Hey chaps, Yes you're on the money there. The issue is that, at least in my case, the relative link to the font file assets are in some CSS. With the VF page appending the query string it means that the assets are not identified as being requested in the first load, and so they are not cached and hence fail. In my instance these are not static resources associated with a managed package, and so I think these CSS files are not automatically annotated (which I think is what will happen following Summer '16 - hat tip to AndyInTheCloud and John Belo to a partner alert). Commented Jun 2, 2016 at 7:51
  • 1
    @ToddHalfpenny Your update to the question seems like a good candidate for an answer. It identifies the cause and has a possible work around. I'm not sure you will get more details than that outside of the support case or a product manager jumping in. Commented Jun 2, 2016 at 20:40

1 Answer 1

6

So to answer my own question (thanks @Daniel Ballinger), here's what I've found out through digging;

1) How can I turn this off?

I've come up with a work-around, as I couldn't find a switch to actually turn it off. By using CAPS in my extensions, in both the actual filenames and the references in the Visualforce pages I have found that the query string is not being appended. e.g my assets are now named my-nice-svg.SVG and the VF references are like

{!URLFOR($Resource.ToddStaticTest, 'static-test/my-nice-svg.SVG')}

2) Which extensions are affected?

So far I have found that this seems to be only affecting .eot, .svg,.ttf,.woff

3) What reason is there for this happening?

This behaviour seems to be related to this partner alert and was put in place for files relating to those needed for web fonts. I'm not sure exactly why. It seems a little bit dirty as SVGs can be used for all sorts, not just fonts.

1
  • Thanks for the pointer to the partner alert! As of Winter '17 Patch 16.3, the CSS rewriter is broken. It rewrites .my-class:before { content: '"' } as .my-class:before { content: """ } and .my-class:before { content: "\\" } as .my-class:before { content: "\" }
    – xn.
    Commented Dec 13, 2016 at 22:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .