attachment plain text

[TheBom]

Since i have updated from 2.x to 2.1.x we have a issue with attachments.

On the PC when i click a attachment it opens as a download popup, but here's the catch, when doing this on a mobile phone it opens as a plain text file instead of a download.
How can i fix this?

[Kindred]

That would seem to be a browser issue,  not an smf issue...

[Sesquipedalian]

What is the file extension of the attachment?

What is the true file type of the attachment?

[TheBom]

That would seem to be a browser issue,  not an smf issue...

This was not with version 2.0.4 the case, now with 2.1.4 it is

What is the file extension of the attachment?

What is the true file type of the attachment?

GPX, based on XML

[Sesquipedalian]

If you look in the attachments table in the database, what is specified the MIME type for the affected attachments? (You are looking for the value of the 'mime_type' column in that table.)

[TheBom]

If you look in the attachments table in the database, what is specified the MIME type for the affected attachments? (You are looking for the value of the 'mime_type' column in that table.)

THe mime_type collom is empty with the following files
- TXT
- GPX (for me this one is important)

Following the PHP manual it should be application/gpx+xml

[Sesquipedalian]

Interesting. It looks like there are a couple of things going on here.

First, there is the fact that the MIME type is empty.

PHP uses the server's MIME type detection library to determine the correct MIME type for a file. If the server's copy of this library doesn't contain a definition to detect GPX files specifically, it might fall back to something generic like 'text/xml' or perhaps just return false. In your case, it looks like the attempt returned false, which resulted in an empty MIME type being saved for those files.

Second, there is the matter of how the file is being handled when downloaded.

When there is no known MIME type for the file, SMF will serve the file using the generic 'application/octet-stream' MIME type and the 'Content-Disposition: attachment' header. The 'Content-Disposition: attachment' header tells the browser that it should save the data as a file rather than displaying it inline. For web browsers on computers, that is pretty much always what happens. However, web browsers on mobile devices will sometimes ignore the 'Content-Disposition: attachment' header and try to display the content inline, especially if the MIME type is 'application/octet-stream'. That appears to be what is happening in your case.

Unfortunately, fixing this might be a little bit tricky for you.

For your existing attachments, you can run a simple database query to set the MIME type to 'application/gpx+xml' for the relevant attachment files. Once that MIME type is set, mobile browsers will probably stop ignoring the 'Content-Disposition: attachment' header.

However, this won't help with new GPX file attachments that your members upload. Until your MIME type detection library is updated, PHP will continue to fail to detect the correct MIME type for those new files. SMF can't do anything about that, because SMF depends on PHP for this task, and PHP depends on the server's operating system.

In order to update the server's MIME type detection library, you will need to talk to your hosting provider.

If your hosting provider is unable or unwilling to update the server's MIME type detection library, you could try creating a modification for SMF that would intervene during the attachment upload process in order to detect these GPX files and set the correct MIME type. However, using an SMF modification for this job will probably not be as reliable as using an up-to-date MIME type detection library, so you should definitely try to get your hosting provider to update that library first.

[TheBom]

Thank you for your explanation.

I'm my own hoster, so that would be easy to fix But... I have looked this up in /etc/mime.types and the following is in it:
application/gpx+xml                            gpx

When i look up this from shell i get the following:
[root@server attachments]# file --mime-type -b 536_724d7cf80b66a0f1e26aed243fe6151062116921.dat
application/xml
[root@server attachments]# file --mime-type -b test.gpx
application/xml

Where the .dat file is from the forum and the test.gpx is the same file i uploaded manually with ftp.
Ofcourse i can run a cron that do every day or more to do a sql command to fix this but i dont know if that can do any harm and what i need to run, i have to investigate this first.


it is also strange since in the previous version 2.0.19 i never had any issue's. I have opened the backup of before the upgrade and looked at first in the SQL, also the mime type is empty there for GPX files.
I did a full restore of this backup to my test sub domain and it popup's like a download and not plain text.

So i don't think this is a server issue for most part but also something different with 2.0.19 vs 2.1.4
To test i added a example GPX file to this post to see what will happen.

Edit: Same happens here on this forum it opens as plain text on a mobile phone instead of a download. This is not the case with SMF 2.0.19

[Kindred]

yes, there is something different. SMF 2.1.x appended the .dat file extension (for reasons) -- which means, if the mime-type is not defined in the database, the browser will probably fall back on "what do I do with .dat files?"

2.0.x had no file extension, so the browser had nothing to fall back on.

The real issue is that your server is not adding the filetype into the database when files are attached.

[TheBom]

The real issue is that your server is not adding the filetype into the database when files are attached.

Okay i can understand this but this is also happening here on this forum if you try my attachment i added to my previous post

[Kindred]

the file opens as an XML file for me, because my PC does not know what to do with a GSX file...  so, it opens as an XML, since that what the file is....

[TheBom]

the file opens as an XML file for me, because my PC does not know what to do with a GSX file...  so, it opens as an XML, since that what the file is....

I think your missing my point here. Your blaming my hosting for not putting this in the database.
But the same happens on this forum, and 2 other test hosting's i have tried.

I hope @Sesquipedalian will know what to do

[Arantor]

yes, there is something different. SMF 2.1.x appended the .dat file extension (for reasons) -- which means, if the mime-type is not defined in the database, the browser will probably fall back on "what do I do with .dat files?"

2.0.x had no file extension, so the browser had nothing to fall back on.

The real issue is that your server is not adding the filetype into the database when files are attached.

Yes but also no. The .dat extension is a complete red-herring and when it is served, it is served with the stored MIME type, or a generic one.

If a browser chooses to infer something else, that's on the browser.

That said, there is a change in how this worked, in that 2.0 basically said "is it an image, then I'll treat it as an image otherwise I'm going to treat it as a binary blob that I neither know nor care about the internals".

2.1 "does this properly". As in, it tries to identify the file type and reflect that back to downloaders, however the methodology used follows an increasingly annoying pattern where "but it's best practice". The problem with following best practice is that a) everyone else isn't and b) best practice has a surprising number of holes in it wheh applied to the real world.

The theory of "let's use a magic (actual term) database to identify a file type" is great until it isn't. Here, what you have isn't an XML file, but it's what will be identified because identifying sub formats is hard at best and impossible at worst. Sometimes the correct approach is to use the information you do have and start from there (namely the file extension!)

This is unlikely to be fixed in 2.1 because even if the magic database is updated, the odds it will correctly identify a sub format of XML that isn't super well known (SVG is, and that's not 100% reliable, the minute you start to hit anything less well known than, say, MathML you almost might as well not bother)

And to fix that requires not following best practices and keeping a list of file extensions and maybe starting your own magic database for. Caution: deep dark pit of rabbit hole exists ahead.

Alternatively you do what 2.0 did, and treat everything you don't explicitly have a supported path for as unknowable black boxes. Also not best practice.

[Sesquipedalian]

Hey, look at that. It looks like there is indeed a bug in SMF 2.1's logic for setting the Content-Disposition header for attachments. On this line, those !== comparison operators should most likely be === operators. Try changing that in your local copy, @TheBom, and please let us know if that fixes the problem for you on mobile browsers.

This issue has been logged as #8098.

[TheBom]

Hey, look at that. It looks like there is indeed a bug in SMF 2.1's logic for setting the Content-Disposition header for attachments. On this line, those !== comparison operators should most likely be === operators. Try changing that in your local copy, @TheBom, and please let us know if that fixes the problem for you on mobile browsers.

This issue has been logged as #8098.

O, you have to help me a little more to what i need to change, i have found the line in my local copy but i'm not fully sure what to change it to, it looks like this line is also mentioning video/audio.

If you mean like this nothing changes:

Code Select Expand

    if (isset($_REQUEST['image']) || (isBrowser('is_mobile') && (strpos($file['mime_type'], 'audio/') === 0 || strpos($file['mime_type'], 'video/') === 0)))

BUT If i change rule 337 to:

Code Select Expand

$disposition = 'attachment';A miracle happens! Its starts as a download! Whoooo!        But ofcourse setting line 337 to this is just a confirmation indeed it is something wrong with line 336 but it is not the === for somehow

[Sesquipedalian]

Does the download URL that you are using have ';image' in it? That URL query parameter exists in order to force 'Content-Disposition: inline' to be used in certain cases.

[TheBom]

Does the download URL that you are using have ';image' in it? That URL query parameter exists in order to force 'Content-Disposition: inline' to be used in certain cases.

Code Select Expand

/index.php?action=dlattach;attach=1327
I'm also using the default smf theme to rule that out (ofcourse). Maybe worth mentioning that.

[Sesquipedalian]

Hm...

For diagnostic purposes, please make the following temporary change in the ShowAttachments.php file.

Code (Find) Select Expand

// On mobile devices, audio and video should be served inline so the browser can play them.
if (isset($_REQUEST['image']) || (isBrowser('is_mobile') && (strpos($file['mime_type'], 'audio/') !== 0 || strpos($file['mime_type'], 'video/') !== 0)))
$disposition = 'inline';
else
$disposition = 'attachment';


Code (Replace) Select Expand

// On mobile devices, audio and video should be served inline so the browser can play them.
if (isset($_REQUEST['image']))
{
if ($user_info['is_admin'])
{
file_put_contents('derp.txt', __LINE__ . ':' . var_export($file, true));
}

$disposition = 'inline';
}
elseif (isBrowser('is_mobile') && (strpos($file['mime_type'], 'audio/') === 0 || strpos($file['mime_type'], 'video/') === 0))
{
if ($user_info['is_admin'])
{
file_put_contents('derp.txt', __LINE__ . ':' . var_export($file, true));
}

$disposition = 'inline';
}
else
{
if ($user_info['is_admin'])
{
file_put_contents('derp.txt', __LINE__ . ':' . var_export($file, true));
}

$disposition = 'attachment';
}

Then, while logged into your admin account, attempt to download the attachment using a mobile device. That will create a file named 'derp.txt' in your forum's base directory. Please attach a copy of the derp.txt file to your next reply here so that I can see the contents. Once you have done so, you can revert those temporary changes to your ShowAttachments.php file.

Also, just to be clear, changing 'inline' to 'attachment' on line 337 is not a good solution for your issue. It may cause the desired behaviour to happen for your GPX files, but it will also break other stuff. Based on your comments, I think you already realize that, but I just want to make sure that is clear.

[TheBom]

Oh i feel so stupid right now... 

It seemed like your fix with !== to === is indeed working...
It was al about caching in the mobile browser that fooled me when clicking the attachment on the forum. The derp file got empty and empty so after troubleshooting....
When refreshing the download page (with the plain text) itself

Code Select Expand

/index.php?action=dlattach;attach=1327 it was presented as a download instead of raw text.

There was nothing wrong at the first place with your === fix... 
I got the derp file if you still want it, sorry..   

But from this derp file i see something intressting

Code Select Expand

  'fileext' => 'gpx',
  'id_attach' => '1327',
  'id_thumb' => '0',
  'attachment_type' => '0',
  'mime_type' => 'text/xml',

Well look at that... it knows its a text/xml file... in the sql database the mime_type is empty but still the forum is fully aware of its mime type..

[Sesquipedalian]

It seemed like your fix with !== to === is indeed working...

Excellent. We'll make sure to put that fix into 2.1.5.

Well look at that... it knows its a text/xml file... in the sql database the mime_type is empty but still the forum is fully aware of its mime type..

That's odd. Nothing in the showAttachment() function tries to populate an empty MIME type. It just uses whatever is retrieved from the database. Unless you have a modification installed that changed something with the showAttachment() function, there's no way that the MIME type could be set unless it is set in the database. But be that as it may, I am glad that we have resolved the issue for you.