SVG upload with CR/LF fails. Change to LF works

Bug
1

After reading

SVG corruption on download of local images

It looks like the process of uploading is breaking the file, somehow. You can run a diff on the original I found on wikipedia: https://upload.wikimedia.org/wikipedia/en/d/d2/Stitch_(Lilo_%26_Stitch).svg

Doing so, it looks like removing linebreaks somehow busted this? The data appears the same, but everything has been moved to a single line rather than being multi-line? Can anyone verify my analysis is correct here?

In testing this idea, copied a simple SVG created with GraphViz on Windows that contained CR (Carriage Return) and LF (Line Feed) and tried an upload. Received the error dialog:

Sorry, but we couldn’t determine the size of the image. Maybe your image is corrupted?

Then using a text editor (NotePad++) used the menu option View -> Show Symbol -> Show All Characters to see the line end characters; they were CR/LF. Changed them to LF, saved the file and uploaded. :smiley:

ast_transformation_derivative_constant_after%20(linux)

2

What exactly are you reporting? The other topic you referenced is very old and out of date so I have deleted it.

3

That uploading an SVG that contains CR/LF will fail with error message. However uploading an SVG that has the CR/LF converted to LF will work.

In other words, if a user sees the error message:

Sorry, but we couldn’t determine the size of the image. Maybe your image is corrupted?

How are they to know that one of the problems is that they should change the CR/LF to LF

or another option is that

discourse should modify the security scanner/whistleblower to allow CR/LF as valid. :smiley:

2 Likes