SVGZ isn't served with correct encoding

I tried to apply the patch, but it failt applying on core/modules/system/css/system.theme.css and core/modules/toolbar/css/toolbar.icons.css because of some changes in the css files.

There also have been added some new svg files that need to be converted to svgz:

• 787878/cog.svg
• 787878/key.svg
• 787878/move.svg
• bebebe/chevron-disc-left.svg
• bebebe/chevron-disc-right.svg
• bebebe/cog.svg
• bebebe/key.svg
• bebebe/move.svg

This looks good to me. It would be great to have this in drupal.

The only thing I am not sure about is the web.config. I can't really test that in any way, so it would be great if someone with a Windows machine could test that.

Tagging to see if someone with a windows machine will take a look. Patch still looks good to me.

Update pantheon info.

Sounds good to me, just wondering if providing two static files with the same content (svg and svgz) is the best approach or if we shouldn't include a process to generate the compressed versions on the fly. That way this would be done dynamically even if anyone added more SVG files further down the road - either in core or in contrib.

That patch screws up IIS pretty bad.

I downloaded the latest d8 via git. Installed, and tested. Worked fine.

Then I applied the patch. Now, the HTML gets generated, but all assets get 500 Internal Server Errors. This includes css, js, and images.

Let me know if there's anything you want me to try, or any more info I can get you. :)

Also, this was tested under IIS 7.5 running PHP 5.4 on Windows Server 2008R2 SP1.

Screenshots below:

Drupal 8 working before patch:

After patch:

I found the issue. The problem was that the patch was redeclaring the svg mime type (which isn't allowed).

Removing the <mimeMap fileExtension=".svg" mimeType="image/svg+xml" /> line fixes the problem.

So, the web.config should read:

    <staticContent>
      <mimeMap fileExtension=".svgz" mimeType="image/svg+xml" />
    </staticContent>

Removing that line fixes the issue, and I successfully tested with Chrome, FF, and IE.

Confirmed that patch in #10 applies and works perfectly for IIS.

Let me know if there's anything else. :)

On a related note, I have just confirmed with Support at Pantheon that SVG compression itself is not currently supported on Pantheon. It IS on the near-term roadmap for new features, but it is NOT yet in production (or even being beta tested). The SVGZ support in the OP IS present, just not any SVG compression.

I have added a request that it be added (one more person requesting can't hurt). If this feature is important to you and you're a Pantheon client (as I am), please let them know this feature is really important to you, and maybe they'll bump it up the queue?

Cheers,
Kelly Bell

Let me try again.

1. +++ b/.htaccess
   @@ -24,6 +24,10 @@ ErrorDocument 404 /index.php
   +# Add correct encoding for SVGZ.
   +AddType image/svg+xml svg svgz
   +AddEncoding gzip svgz
   
   +++ /dev/null
   index b072d9b..90ebf1b 100644
   --- a/web.config
   

   These are clear wins, because they ensure the web server supports commonly used file formats. They also don't affect the TX.

2. +++ b/core/themes/bartik/color/preview.html
   @@ -1,7 +1,7 @@
   diff --git a/core/themes/bartik/logo.svg b/core/themes/bartik/logo.svg
   deleted file mode 100644
   index 7d7cf7c..0000000
   --- a/core/themes/bartik/logo.svg
   +++ /dev/null
   @@ -1 +0,0 @@
   -<svg xmlns="http://www.w3.org/2000/svg" width="57" height="66" viewBox="471.5 467 57 66" enable-background="new 471.5 467 57 66"><path opacity=".2" fill="#303030" d="M528.5
   […]
   -6.08z"/></svg>
   diff --git a/core/themes/bartik/logo.svgz b/core/themes/bartik/logo.svgz
   new file mode 100644
   index 0000000000000000000000000000000000000000..a91a1391fb26ed2d2c4d7c6011bfd8a2de719627
   GIT binary patch
   literal 1892
   zcmV-q2b=gGiwFpjn&DIe18i?+Z!U9oX8?Vd%W@>Q5k>d@3PgKd7$EU>h+1gxkDyvJ
   […]
   

   (And same for many other SVG files.)
   These aren't clear wins.

   I'm all for improving front-end performance, but it feels like this might be too intrusive for the TX.

   It's easy enough: rename a SVGZ file to "SVG.GZ", then it's extractable like any gzip file (on OS X), and you get the original SVG to work with.

   But why do we have to ship with this? Why can't it be up to the web server to do this?

   Finally: this part of the patch does not match the issue title/IS.

Please consider doing only the "support SVGZ" bit in this patch, then it can go in easily. Converting Drupal core's SVGs can be a follow-up issue.

Thanks!

Only thing preventing me from RTBC'ing this: a beta evaluation. Please add that to the IS, then this is RTBC!

For #28.

Thanks for the beta evaluation!

Super nitpicky nitpick that can be fixed upon commit:

+++ b/core/modules/system/src/Tests/System/HtaccessTest.php
@@ -38,4 +38,13 @@ protected function assertNoFileAccess($path) {
+  }
 }

We put a newline after the last method.

This issue is a normal bug fix, and doesn't include any disruptive changes, so it is allowed per https://www.drupal.org/core/beta-changes. Committed 84c2ccf and pushed to 8.0.x. Thanks!

@jbrown: I'm afraid you'll have to file a new issue.

Does this still need porting to 7.x per #35?

Here's a patch for D7.

Patch in #43 works for me, thanks.

This should be included in Drupal 7 too. Patch #43 do the work.