Special characters in GPX track name

[Phyks]

Hi,

It seems when exporting a GPX track the name can contain special characters, whereas the validation regex does not allow them. I don't think there could be issues allowing them, so the regex should probably be updated to take them into account.

E.g. : http://brouter.de/brouter-web/#map=13/47.7284/-3.4361/CyclOSM&lonlats=-3.472018,47.71177;-3.467302,47.721397;-3.455973,47.737273;-3.399582,47.75698;-3.433828,47.745672;-3.44636,47.721081;-3.468418,47.713631

Thanks!

[nrenner]

Now that we have escape functions in StringUtils (abrensch/brouter#201, #194), we should use those for the track name also, i.e. not apply the regex in ServerHandler.formatTrack, but escape the name in each OsmTrack.formatAs* method accordingly.

Don't know if there is a recommended set of characters to remove from file names that works for all operating systems and cases, that we could use instead of allowing just a strict set of characters for the download file name in ServerHandler.getFileName (see also #202).

[Phyks]

Don't know if there is a recommended set of characters to remove from file names that works for all operating systems and cases, that we could use instead of allowing just a strict set of characters for the download file name in ServerHandler.getFileName (see also #202).

Is there really a need for escaping there?

Something like

<a href="https://www.w3schools.com/images/myw3schoolsimage.jpg" download="toto/bidule.html">
  <img src="https://www.w3schools.com/images/myw3schoolsimage.jpg" alt="W3Schools" width="104" height="142">
</a>

works perfectly fine in Firefox and yields a download window for a file named toto_bidule.html. Special characters handling seems to already be done at browser level.

[nrenner]

Is there really a need for escaping there?

I don't know. @bagage ?

Special characters handling seems to already be done at browser level.

Would be great and make sense if browsers removed special/unallowed characters in file names. But to be sure we should do some research if that is a MUST in a spec supported by all browsers.

Note that we don't use the download attribute, but the Content-Disposition header in RouteServer.java. So it's also a matter of HTTP header specs. From some quick search:

• Content-Disposition - HTTP | MDN
• How to encode the filename parameter of Content-Disposition header in HTTP? - SO (old)

[bagage]

Is there really a need for escaping there?

Not sure either.

According to RFC, Content-Disposition filename value must be encoded as RFC2616, Section 3.6:

       value          = token | quoted-string
       token          = 1*<any CHAR except CTLs or separators>

So basically no escaping seems required.

[nrenner]

Now with client-side download, Content-Disposition header and HTTP encoding don't matter anymore.

Spec quotes regarding the download attribute:

If the name is not a valid file name in the underlying OS, the browser will adjust it.

HTMLAnchorElement.download - Web APIs | MDN

There are no restrictions on allowed values, but [...] user agents are likely to adjust filenames accordingly.

download attribute - 4.6.2 Links created by a and area elements - HTML Standard

This algorithm is intended to mitigate security dangers involved in downloading files from untrusted sites, and user agents are strongly urged to follow it.

14. Adjust filename to be suitable for the local file system.
    For example, this could involve removing characters that are not legal in filenames, or trimming leading and trailing whitespace.

as a download - 4.6.5 Downloading resources - HTML Standard

So I think it's safe to remove our filename replacement and to rely on the browser to sanitize, assuming they do follow when "strongly urged". The still available old server download will keep replacing the name in the server (just no WYSIWYG anymore).

Already implemented (7aa2fcb) and released.