In T428006#12001108, @sbassett wrote:

@SomeRandomDeveloper - Are you aware of any legitimate reason we'd need to actually publicly serve these files? Either for Wikimedia or Miraheze?

I am not aware of any reason they need to be served. We need to store them though as they are used when displaying a cached timeline, and I'm not sure whether there's an easy way to store them without serving them. It probably depends on the file backend, and ideally we should find a solution that works with all types of file backends

I feel like the easy approach is to just deprecate the generation/output/serving of the .map files. Timeline defines image maps via proper <map> tags in html which has been browser-supported since... the mid-1990s. I just can't imagine the .map files are relevant anymore and I don't see how that should affect Wikimedia caching. Not to mention the fact that they conflict with far more modern/common JS source map files of the same extension that most developers would probably expect.

In T428006#12005537, @sbassett wrote:

I feel like the easy approach is to just deprecate the generation/output/serving of the .map files. Timeline defines image maps via proper <map> tags in html which has been browser-supported since... the mid-1990s. I just can't imagine the .map files are relevant anymore and I don't see how that should affect Wikimedia caching. Not to mention the fact that they conflict with far more modern/common JS source map files of the same extension that most developers would probably expect.

The contents of the HTML <map> tag for a timeline are generated by retrieving the .map file and cleaning up the XML, so unfortunately we will still need to generate it unless we decide to store the data somewhere else.

I think you could tell swift a different MIME type when storing these files.

In T428006#12008565, @MatthewVernon wrote:

I think you could tell swift a different MIME type when storing these files.

Yeah, I think storing them as text/plain would probably guarantee some better safety here? Like so:

$op = [
    'op'  => 'store',
    'src' => "{$factoryDirectory}/file.{$ext}",
    'dst' => "{$pathPrefix}.{$ext}",
];
if ( $ext === 'map' ) {
    $op['headers'] = [ 'Content-Type' => 'text/plain; charset=utf-8' ];
}
$ops[] = $op;

within the timeline file storage loop. It looks like this could also be set via $opts in doQuickOperations(), but that doesn't seem preferred from my read of the docblock? Until we refactor timeline to discard the image map files after they're used or generate that source some other way, this is probably the simplest approach.

Formalized my suggestion above into a patch:

In T428006#12082596, @sbassett wrote:

Formalized my suggestion above into a patch:

01-T428006.patch1 KBDownload

I feel like this could probably just go through gerrit, tbh. It also only satisfies the condition where media/file backends (like Swift) support writing a content-type for a given asset. For plain installations of MediaWiki, this would still likely need to be managed at the web server layer.

Deployed

This seems to be working in production when I recreate the example at https://test.wikipedia.org/wiki/User:SBassett_(WMF)/Sandbox/Test. The image map functionality still appears to work with the PNG that gets included on User:SBassett_(WMF)/Sandbox/Test. And the map functionality also still works for the raw SVG: https://upload.wikimedia.org/wikipedia/test/timeline/p73kykc82kwrqwwg0aqd2ti98ypdmdx.svg. And the map file is being served as plain text: https://upload.wikimedia.org/wikipedia/test/timeline/p73kykc82kwrqwwg0aqd2ti98ypdmdx.map. The big caveat is that this is a point-in-time-forward fix, in that it does not retroactively fix any potentially problematic existing map files.