Text attachments should display in the browser, not forced downloaded

cracauer@ · Saturday at 8:36 PM

Text attachments should display in the browser, not forced downloaded.

Consider the first post here: https://forums.freebsd.org/threads/audinst-hud-mx1usb-dac-sound-volume-very-low.102321/

I want to see dmesg. As it is right now I have to download it, open it from HD and then clean up afterwards. It should just display the text in a browser tab. This is done via http header.

I know that XenForo does this by default and last I heard there was no option to turn this nonsense off. But maybe there us a way, or an update or something.

drsnx60 · Sunday at 9:13 AM

using firefox to navigate to

file:///var/run/dmesg.boot

And opening it works for me and displays text in the firefox window.

mer · Sunday at 9:28 AM

drsnx60 said:
using firefox to navigate to

file:///var/run/dmesg.boot

And opening it works for me and displays text in the firefox window.

That works for files on the local system, but I believe cracauer@ is talking about text files that someone attaches to a post on the forum. The thread linked in the OP has 3 attachments, all text files. If you want to look at the contents, clicking on one causes a download, not just open in a new tab.

drsnx60 · Sunday at 9:45 AM

OK. I can configure the DOWNLOAD setting in firefox to "Always ask you where to save files"
this pops up a dialouge where I can view the file in an editor or I can select a browser to view the file in .

fjdlr · Sunday at 2:22 PM

I have two scripts; one monitors the download of text files.
The other opens hx or vim to view the file.
Install pkg install entr
You can change the editor.
Sorry, the comments are in French.
15:32 %> cat watch-txt.sh

#!/bin/sh

DL="$HOME/Telechargement"
CACHE="/tmp/hx_last_opened_txt"

[ -d "$DL" ] || exit 1

# surveille le dossier lui-même
while true; do
printf '%s\n' "$DL" | entr -d sh -c '
DL="'"$DL"'"
CACHE="'"$CACHE"'"

FILE=$(find "$DL" -maxdepth 1 -type f -name "*.txt" -print 2>/dev/null \
| xargs ls -t 2>/dev/null | head -n 1)

[ -n "$FILE" ] || exit 0

MTIME=$(stat -f "%m" "$FILE" 2>/dev/null) || exit 0
NOW=$(date +%s)
AGE=$((NOW - MTIME))

# ignorer les vieux fichiers
[ "$AGE" -gt 5 ] && exit 0

LAST=""
[ -f "$CACHE" ] && LAST=$(cat "$CACHE" 2>/dev/null)

# éviter de rouvrir le même fichier
[ "$FILE" = "$LAST" ] && exit 0

echo "$FILE" > "$CACHE"

# laisser finir le renommage / flush Firefox
sleep 1

exec xfce4-terminal --hold -e "hx \"$FILE\""
'
done

and
15:33 %> cat open-last-txt.sh

#!/bin/sh

DL="$HOME/Telechargement"

# dlast file downloaded
FILE=$(ls -t "$DL"/*.txt 2>/dev/null | head -n 1)

[ -z "$FILE" ] && exit 0

# open helix
exec hx "$FILE"

my editor is hx

kent_dorfman766 · 2026-04-13T04:56:42+0100

The web server should be identifying the content as text/plain so that the browser can display it. Instead they are either not assigning any mime type or a wrong one, so the browser falls back to binary download of content.

cracauer@ · 2026-04-13T12:58:14+0100

kent_dorfman766 said:
The web server should be identifying the content as text/plain so that the browser can display it. Instead they are either not assigning any mime type or a wrong one, so the browser falls back to binary download of content.

No, that's not true. The web server sends the right mime type, but also another header forcing the download.

blackbird9 · 2026-04-13T13:16:25+0100

Using waterfox on windowmaker, it asks me to save the file, as the only option presented. However using waterfox on kde plasma, it gives me an option to either save the file or open it with an editor (kate), if I chose editor it opens the file in a separate window in the editor, and does not save it to the local drive (unless it's creating a temporary somewhere that it deletes automatically afterwards). So it appears that the desktop environment being used modifies the dialog that is presented when clicking on the link.

cracauer@ · 2026-04-13T13:57:35+0100

blackbird9 said:
Using waterfox on windowmaker, it asks me to save the file, as the only option presented. However using waterfox on kde plasma, it gives me an option to either save the file or open it with an editor (kate), if I chose editor it opens the file in a separate window in the editor, and does not save it to the local drive (unless it's creating a temporary somewhere that it deletes automatically afterwards). So it appears that the desktop environment being used modifies the diaglog that is presented when clicking on the link.

If it's in the editor it is on a filesystem. You can find out where by trying to save the buffer after a modification.

Kai Burghardt · 2026-04-13T15:00:06+0100

cracauer@ said:
No, that's not true. The web server sends the right mime type, but also another header forcing the download.

I can not confirm that.

Bash:

curl -so dmesg.txt --dump-header - https://forums.freebsd.org/attachments/dmesg-txt.25923/

shows

HTTP:

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 13 Apr 2026 13:45:55 GMT
Content-Type: application/octet-stream
Content-Length: 2706
Connection: keep-alive
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Last-Modified: Mon, 13 Apr 2026 13:45:55 GMT
Content-Disposition: attachment; filename="dmesg.txt"
ETag: "1775934141"
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: private, no-cache, max-age=0
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

RFC 2616 explains that if a Content‑Disposition

[…] is used in a response with the application/octet-stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a ‘save response as …’ dialog.

Therefore to fix the problem is to properly detect and send text/plain as the Content‑Type. I just verified that file --mime dmesg.txt can do it. There are apparently no strange characters confusing recognition algorithms.

cracauer@ · 2026-04-13T16:38:39+0100

Hmmm, I thought I had observed that in Chrome's webdev. Must have been some other site where the same problem appears. Maybe bugs.freebsd.org? Apologies.

Your analysis and proposed solution is sound then.

Mjölnir · 2026-04-13T18:17:43+0100

drsnx60 said:
OK. I can configure the DOWNLOAD setting in firefox to "Always ask you where to save files"
this pops up a dialouge where I can view the file in an editor or I can select a browser to view the file in .

That's several mouseclicks. The OP wants it to be just ONE.
[EDIT] In KDE (konqueror) it's right mouse button -> preview in... -> embedded enhanced text editor

danger@ · 2026-04-13T19:16:34+0100

Kai Burghardt said:
I can not confirm that.

Bash:

curl -so dmesg.txt --dump-header - https://forums.freebsd.org/attachments/dmesg-txt.25923/

shows

HTTP:

HTTP/1.1 200 OK Server: nginx Date: Mon, 13 Apr 2026 13:45:55 GMT Content-Type: application/octet-stream Content-Length: 2706 Connection: keep-alive X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff Last-Modified: Mon, 13 Apr 2026 13:45:55 GMT Content-Disposition: attachment; filename="dmesg.txt" ETag: "1775934141" Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: private, no-cache, max-age=0 Strict-Transport-Security: max-age=31536000; includeSubDomains X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block X-Frame-Options: SAMEORIGIN

RFC 2616 explains that if a Content‑Disposition
Therefore to fix the problem is to properly detect and send text/plain as the Content‑Type. I just verified that file --mime dmesg.txt can do it. There are apparently no strange characters confusing recognition algorithms.

this investigation is correct, however attachments are being handled by XenForo and it is XenForo which sets the Mime-type (Content-Type header); unfortunately it sets incorrect mime type (application/octet-stream instead of text/plain) in this case. It only handles image attachments correctly, all other attachments are sent as application/octet-stream. This is something that would require a fix upstream or an addon (which we do not prefer).

cracauer@ · 2026-04-13T19:44:14+0100

I know XenForo doesn't support it. I'd say hack up the PHP code. Just send content type text instad of octeats. Easy peasy.

Maxnix · 2026-04-13T20:15:40+0100

As a workaround for Firefox there is this extension (don't know for Chromium): https://addons.mozilla.org/en-US/firefox/addon/open-in-browser/.

AlfredoLlaquet · 2026-04-13T21:08:23+0100

I don't agree. I think they should be automatically zipped and sent to your most current email address unless you live in California. If you live in California, they should be printed and manually faxed to you.

Also, I think there should be a PinkFreeBSD theme. Why is there a BlueFreeBSD theme, but not a PinkFreeBSD theme?

Why?!?!

Why?!?!

cracauer@ · 2026-04-13T21:19:45+0100

I'm sure there is such an extension for Chrome, too, but it is hard to Google for it.

DutchDaemon · 2026-04-14T07:47:00+0100

cracauer@ said:
I know XenForo doesn't support it. I'd say hack up the PHP code. Just send content type text instad of octeats. Easy peasy.

To say XenForo has made this non-trivial (not to say extremely convoluted) is an understatement. That is the reason why the existing add-on for XF1 was never ported over to XF2, and why XF developers keep holding off on offering the option. Don't expect a Q & D solution from volunteer staff here. Sorry.

eternal_noob · 2026-04-14T09:31:38+0100

That’s a basic web feature, and since XenForo costs a fortune, I’d flood their forums with complaints until they fix the problem.

Text attachments should display in the browser, not forced downloaded

cracauer@

drsnx60

mer

drsnx60

fjdlr

kent_dorfman766

cracauer@

blackbird9

cracauer@

Kai Burghardt

cracauer@

Mjölnir

danger@

Administrator

cracauer@

Maxnix

AlfredoLlaquet

cracauer@

DutchDaemon

Administrator

eternal_noob