Hugo: Server serving `svg` with mimetype `image/svg` instead of `image/svg+xml`

[cirocosta]

Hey,

Firstly, thanks for putting so much effort on Hugo!

I just update Hugo to v0.43/extended darwin/amd64 BuildDate: 2018-07-09T10:21:26Z in order to test the resource bundling & minification functionality (coming from v0.40 I guess), and I noticed that my svg images don't render in Chrome anymore when using hugo serve.

Looking further into it, that's due to the server serving the images as image/svg instead of the standard image/svg+xml:

hugo serve ^

http-server -p 1313 ^

I guess this is a known issue given the following comment (https://github.com/gohugoio/hugo/blame/dea71670c059ab4d5a42bd22503f18c087dd22d4/media/mediaType.go#L97):

// The official MIME type of SVG is image/svg+xml. We currently only support one extension
// per mime type. The workaround in projects is to create multiple media type definitions,
// but we need to improve this to take other known suffixes into account.
// But until then, svg has an svg extension, which is very common. TODO(bep)

Given that this is a regression and is something known, maybe we could work on the docs to provide such explanation and an example of how to work around it?

Thanks very much!
Ciro

[bep]

OK, so this was the reason why those SVGs vanished from the server ... I didn't think about the server when I made the comment above.

[martinrode]

This is a regression between 0.43 and 0.42.1 in my tests....

0.42.1 > GOOD

martin@easydb-vm:~/easydb/5/apitest$ HEAD http://10.150.0.2:1313/easydb-documentation/images/easydb_logo.svg
200 OK
Connection: close
Date: Mon, 09 Jul 2018 20:29:22 GMT
Accept-Ranges: bytes
Content-Length: 5471
Content-Type: image/svg+xml 
Last-Modified: Tue, 03 Jul 2018 15:17:43 GMT
Client-Date: Mon, 09 Jul 2018 20:29:22 GMT
Client-Peer: 10.150.0.2:1313
Client-Response-Num: 1

0.43 > NO GOOD

martin@easydb-vm:~/easydb/5/apitest$ HEAD http://10.150.0.4:1313/easydb-documentation/images/easydb_logo.svg
200 OK
Connection: close
Date: Mon, 09 Jul 2018 20:29:09 GMT
Accept-Ranges: bytes
Content-Length: 5471
Content-Type: image/svg; charset=utf-8
Last-Modified: Tue, 03 Jul 2018 08:49:47 GMT
Client-Date: Mon, 09 Jul 2018 20:29:09 GMT
Client-Peer: 10.150.0.4:1313
Client-Response-Num: 1

This is both with linux (and mac) binaries from the website....

Did you use a different Go version to compile? I suspect this could be a mimetye issue with the standard library of Golang?

[bep]

@martinrode the cause of this is known; I changed the default media type definition for SVG for some other reason. You can actually work around this yourself by creating a SVG definition yourself, I suspect ... But I will have to think a little about what the fix for this should be. I'm a little bit surprised by how Chrome handles this (but not all versions, I thnk).

[jbarratt]

I found the same display issue in Safari, for what it's worth. If I paste the image URL into a directory in either Safari or Chrome it downloads the image instead of displaying it.

[jbarratt]

I tried creating my own SVG definition in config.toml. This may not be the correct place to do it?

[mediaTypes]
  [mediaTypes."image/svg+xml"]
    suffix = "svg"

It comes back with an error:

ERROR 2018/07/09 14:28:57 Failed to reload config: 
media type keys cannot contain any '+' chars. Valid example is "text/css"

[bep]

@jbarratt OK, you have kind of touched the core of the problem here, the above cannot be expressed with what we have today. I think we need to add another attribute to Media Type, but will need to think about it.

[jbarratt]

Thank you for fixing this! I installed from master, added

[mediaTypes]
  [mediaTypes."image/svg+xml"]
    suffixes = ["svg"]

to my config.toml and it worked.

I tested it without the above block as well -- I will note that since serving SVG files seems to be a pretty common use case, it feels a little strange to have to do what amounts to a "workaround" for them.

[bep]

@jbarratt this is a bug. A blunder. A mistake. By me. You don't need a workaround with the patch I applied. The media type you have specified is the new default in Hugo.

[jbarratt]

Ah, one good bug/blunder/mistake deserves another.

I downloaded & installed the new hugo, hugo serve'd, and shift-reloaded Chrome -- and the images were still broken.

I added the workaround, and it worked! But, that must have just been cache ghosts in Chrome, because now I see that it behaves the same with and without the extra config.toml bits.

Thank you again kind sir!

[cirocosta]

Thanks a lot for putting such great effort on it @bep !

[martinrode]

Hey all, thanks for the bugfix. The 0.45-DEV works for me it delivers:

{{{
martin@easydb-vm:~$ HEAD http://10.150.0.4:1313/images/arrow.svg
200 OK
Connection: close
Date: Wed, 18 Jul 2018 07:11:29 GMT
Accept-Ranges: bytes
Content-Length: 2710
Content-Type: image/svg+xml; charset=utf-8
Last-Modified: Tue, 17 Jul 2018 14:14:56 GMT
Client-Date: Wed, 18 Jul 2018 07:11:29 GMT
Client-Peer: 10.150.0.4:1313
Client-Response-Num: 1
}}}

This is without any additional configuration.