Production issue with CDTS - Header and Foot saving as SFG files

[gsugar]

The latest update to the CDTS common header and footers appears to have introduced a bug. Our production application (link below) as well dev instances are failing to load header and footers properly. They are resulting in Images saved to users local machine as SVG files.

This is an urgent issues as it affecting production application . Likely many application are impacted.
Most users only see the issues after they clear the cache and recieve the latest CDTS templates.
George

Here a link to our production Applicaiotn
https://nnhpd-pla-dlmm-dpsnso.hc-sc.gc.ca/pla-dlmm/

[GormFrank]

Thank you for flagging this issue! We have initiated necessary work in order to resolve it as quickly as possible.

[duboisp]

Curiously, the following page that use CDTS template work fine: https://cenw-wscoe.github.io/sgdc-cdts/docs/index-en.html

\cc @jeanbenoitrochon @StdGit

[jeanbenoitrochon]

@gsugar

CDTS has not released a new version in a while. I was able to reproduce your bug.

However, Looking at the html source code of your site it appears you are using version 26 of CDTS. CDTS is currently at version 32.

<script type="text/javascript" src="https://www.canada.ca/etc/designs/canada/cdts/gcweb/v4_0_26/cdts/compiled/soyutils.js"></script> <script type="text/javascript" src="https://www.canada.ca/etc/designs/canada/cdts/gcweb/v4_0_26/cdts/compiled/wet-en.js"></script>

I also noticed something odd, the file it's prompting me to save on my computer "sig-blk-en.svg" is set to use version 25.
<a href="https://www.canada.ca/en.html"><object type="image/svg+xml" tabindex="-1" data="https://www.canada.ca/etc/designs/canada/cdts/gcweb/v4_0_25/assets/sig-blk-en.svg"></object>

Please try using version 4.0.32 and let me know if that worked.

Thanks,

[crussellgh]

Is the plan to fix this regression and not serve up the new response headers for the SVG files?

From what I can tell everything worked fine till the web server started returning a content-disposition header set to attachment and also x-frame-options set to sameorigin.

Or are we expected to upgrade legacy applications to 4.0.32 to fix this?

[wesmacdonald]

Curiously, the following page that use CDTS template work fine: https://cenw-wscoe.github.io/sgdc-cdts/docs/index-en.html

\cc @jeanbenoitrochon @StdGit

That page uses an img vs. object from what I see in our site.

<object type="image/svg+xml" tabindex="-1" data="https://www.canada.ca/etc/designs/canada/cdts/gcweb/v4_0_24/assets/sig-blk-en.svg"></object>

[jeanbenoitrochon]

Is the plan to fix this regression and not serve up the new response headers for the SVG files?

From what I can tell everything worked fine till the web server started returning a content-disposition header set to attachment and also x-frame-options set to sameorigin.

Or are we expected to upgrade legacy applications to 4.0.32 to fix this?

Thanks for the additional troubleshooting info.

@duboisp Do you know if some settings changed on canada.ca web servers ? It's odd that an older version of CDTS stopped working as expected.

[duboisp]

Yes we have updated the content-disposition header recently for some files on Canada.ca. The x-frame-options header was added 2-3 month ago.

The issue is the image is blocked when it's loaded from an object element. ref. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

I am going to look today if we can add an exception for those svg file.

[duboisp]

\cc @IsabelleWaltzing @JoshSommers

[StdGit]

You could look also in the same time for support of WOOF2 from the server (Referrer Policyno-referrer-when-downgrade ) https://www.perpetual-beta.org/weblog/the-curious-case-of-tls-and-the-missing-referrers.html

[duboisp]

It's seems fixed now

[mcharala]

Folks,

I am have expericed this issue consistantly recently.

Colleagues of mine tell me that the SVG file is prompting a 'NS_BINDING_ABORTED' message while it unsuccessfully caches the SVG logo.

Best,
Mykhailo

Please visit:

canada.ca/commemorative-map

https://maps.canada.ca/journal/content-en.html?appid=3f3247733f244707bb77cd94a3c5ff2f&appidalt=255b1d3aaba446e5b2406977db503f22&locale=fr%3futm_campaign=not-applicable&utm_medium=vanity-url&utm_source=canada-ca_commemorative-map

[StdGit]

Which browser/tools your colleague has used

Is it Firefox?

and what is the version?

[mcharala]

Latest version of Firefox Developer
https://www.mozilla.org/en-CA/firefox/developer/

However, this issues also occurs with Chrome and Explorer

[StdGit]

Yes we have updated the content-disposition header recently for some files on Canada.ca. The x-frame-options header was added 2-3 month ago.

The issue is the image is blocked when it's loaded from an object element. ref. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

I am going to look today if we can add an exception for those svg file.

It's seems fixed now

@duboisp is it fixed for all servers including nhdc310.hrdc-drhc.net ?
the bug is still there.

Also some CSP have been adding
https://nnhpd-pla-dlmm-dpsnso.hc-sc.gc.ca/pla-dlmm/
from https://nnhpd-pla-dlmm-dpsnso.hc-sc.gc.ca/pla-dlmm/
causing errors.

@jeanbenoitrochon Issue is that security has been upgraded but not CDTS.

FYI
In conclusion, SVGs are more like HTML than simply being an image. As a result, we recommend that web developers not load any SVG as an object or iframe if possible. The web administrator should also limit the file types that can be uploaded.

https://www.fortinet.com/blog/threat-research/scalable-vector-graphics-attack-surface-anatomyhttps://www.fortinet.com/blog/threat-research/scalable-vector-graphics-attack-surface-anatomy

[StdGit]

Yes we have updated the content-disposition header recently for some files on Canada.ca. The x-frame-options header was added 2-3 month ago.

The issue is the image is blocked when it's loaded from an object element. ref. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

I am going to look today if we can add an exception for those svg file.

It's seems fixed now

@duboisp is it fixed for all servers including nhdc310.hrdc-drhc.net ?
the bug is still there.

Also some CSP have been adding
https://nnhpd-pla-dlmm-dpsnso.hc-sc.gc.ca/pla-dlmm/
from https://nnhpd-pla-dlmm-dpsnso.hc-sc.gc.ca/pla-dlmm/
causing errors.

@jeanbenoitrochon Issue is that security has been upgraded but not CDTS.

[mcharala]

@StdGit
Hi again, could you please let me know what needs to be changed? Our version is still causing SVGs to auto-download.
view-source:https://maps.canada.ca/journal/content-en.html

[EricDunsworth]

@mcharala FWIW the SVGs on that page seem to be working properly for me. Their HTTP response headers are using Content-Type: image/svg+xml (correct MIME type for SVGs) and I'm not seeing any signs of Content-Disposition: attachment. Might be worth trying to hard refresh (Ctrl+F5) to see if that helps.

The only thing I noticed is that the static HTML fallbacks for that page's CDTS implementation are still using <object> elements for its SVGs instead of <img>. But that shouldn't really matter if the server is serving the SVGs properly.

[StdGit]

@mcharala I don't think the issue is on your end.

I think that what is happening is that security(CSP) has changed on one of the server and your browser is trying to download it
I got the issue few minutes ago.

Firefox tried to download the first time. https://www.canada.ca/etc/designs/canada/cdts/gcweb/v4_0_32/assets/wmms-blk.svg
Second time it displayed it

Some ref
https://css-tricks.com/using-svg/

Another issue could be the format of the svg
https://css-tricks.com/probably-dont-base64-svg/

And you have this error
The character encoding of the plain text document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the file needs to be declared in the transfer protocol or file needs to use a byte order mark as an encoding signature.

You never know – some protocols may interpret your binary data as control characters (like a modem), or your binary data could be screwed up because the underlying protocol might think that you’ve entered a special character combination (like how FTP translates line endings).

So to get around this, people encode the binary data into characters. Base64 is one of these types of encodings.

[mcharala]

@EricDunsworth
Funny enough, I followed your suggestion to replace with and the problem disappeard. Strange.

@StdGit Thank you for the recommendations. I will make sure my colleagues double back and fix the character encoding.

[StdGit]

@mcharala Probably It is on cdts side, not your code :-)

[StdGit]

@mcharala

@EricDunsworth
Funny enough, I followed your suggestion to replace with and the problem disappeard. Strange.

What did you replace and with what? :-)

[EricDunsworth]

@StdGit It was <object> that was replaced with <img>.

@mcharala's comment had the HTML tags in it but they weren't in code blocks (so GitHub filtered out the <object> element and inserted a blank <img>).

[StdGit]

I disagree :-)

The issue is still there. Image is displayed now but the browser tries also to download it.

I think it could be related to

Upgrade-Insecure-Requests	1

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade-Insecure-Requests

But definitively a change in the server or Browsers. Not the code :-)

curl "https://www.canada.ca/etc/designs/canada/cdts/gcweb/v4_0_32/assets/wmms-blk.svg" -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0" -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8" -H "Accept-Language: en-US,en;q=0.5" --compressed -H "Referer: https://github.com/wet-boew/wet-boew/issues/8966" -H "Connection: keep-alive" -H "Cookie: _ga=GA1.2.1562936116.1575302632; AMCV_A90F2A0D55423F537F000101"%"40AdobeOrg=-637568504"%"7CMCIDTS"%"7C18663"%"7CMCMID"%"7C79771798433896836783413300797820803966"%"7CMCAAMLH-1613071666"%"7C7"%"7CMCAAMB-1613071666"%"7C6G1ynYcLPuiQxYZrsz_pkqfLG9yMXBpb2zX5dvJdYQJzPXImdj0y"%"7CMCOPTOUT-1612474066s"%"7CNONE"%"7CMCAID"%"7CNONE"%"7CvVersion"%"7C5.1.1"%"7CMCSYNCSOP"%"7C411-18580; _4c_=jVTbbtswDP2VwQ97qm3dLwWKoe0u2IBu6NZhj4EsyYnRxDYkN15X9N9HuXGSpS"%"2FLQ2wfHh6SIqmnbFz5NjvHAhGsmMBcM3yW3fvHmJ0"%"2FZaFx6bHNzjOMidA1drmjnueMSpabSvpce6Uk4dYx7bKz7PekpQjBQhKl0PNZVldhFnl8xdACGGHYEWqzjv6EojEHyjLUM2mfK2GavSJPenYOOIQHfxKTYsSA49qZE7zzsVm2r3iUAq"%"2Fpj"%"2BIixrhkmkt"%"2BwuVq4s6S5lTrxR7Gg1QySI45k8fUFwSott9Rn7KHsAbJ1TD08bwsu963hTWtcQYepU9p"%"2BzYF7UNqgO2cT"%"2B3SBaYFyusI2PAHkJwwBO"%"2Ffbu6"%"2BL64"%"2BXF5"%"2F"%"2B3qkuhOMtug2Q3C2aP1QVmWMO8u62fqNadoSl19"%"2B5KRQBcnfy9uvZURSKIQIZ"%"2FBP5bvL26sL"%"2FHbTuAuppcRSK0YpdFlRIRVlcKYIgUURpBDVQry9vP1wgSGv4Pu1eVykgcs22ljsBa0QIwwbUxmnuCPEIwMiujrQo4"%"2Bx6dqdG0OIM"%"2BO4QRii1jCeTjNXYS04VoaCWx8692CHxfDYp1MaffUmunswOL9trF"%"2BMjRtW0"%"2FERdEBXvlmuhgRD1gnuQ"%"2FqAt7FpXTeeuu3QvZvGDNAqdGP0yfNjE3zd"%"2FX4ziXWwadmvySNOhdU"%"2BhIk2N2ccx2LZdcu1L2y3KYEUmyGlvx"%"2BDHQRrO6ONaZfdNlWcRiOVvu6sWSevaWTuQrNc"%"2BnDjh1WXzu4ugM8AR2nW2ctyHO"%"2BFS1XA1"%"2F3Q9UfwNEs315"%"2Ffg"%"2FX"%"2F2g1Ony4XPycPzAXRVGAsCgwbRRERlGTP8zoQIjHClDENAzzACigB"%"2FYUfMLb7TauEtcRVLKeVMzmrcZ0rS"%"2BvcaUKsqZn19LCMcG0IhiEo3UliNStuDjfdf0zfi5zWAk23EJ9uuWoWiNm"%"2FNRwF3Nfw"%"2FPwX; mbox=PC#339c3913bdf0457a871aa7bce048018b.35_0#1675712394|session#7f4c8ce41b5a47668e5034ae41571b4c#1612468725; aka-ca-site-token=e2af4543e36e00006de040606c030000f03b6900" -H "Upgrade-Insecure-Requests: 1" -H "Pragma: no-cache" -H "Cache-Control: no-cache"

[EricDunsworth]

FWIW those SVG files are currently being served to me using Content-Disposition: attachment in Firefox and without it in Edge. So they're probably not synched properly across Akamai's cloud servers. Whether or not they get served properly is probably luck of the draw based on which server you hit.

@duboisp @GormFrank Thoughts?

[StdGit]

I noticed that content-disposition is not there all the time.
When is not there, browser doesn't try to download.
Note Tested with Firefox 80.0.1 (64-bit).