Skip to content

Can't download CSV attachment (just opens in browser) #8667

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
1 of 4 tasks
bobemoe opened this issue Oct 24, 2019 · 9 comments
Closed
1 of 4 tasks

Can't download CSV attachment (just opens in browser) #8667

bobemoe opened this issue Oct 24, 2019 · 9 comments
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented

Comments

@bobemoe
Copy link
Contributor

bobemoe commented Oct 24, 2019

Description

I'm trying to attach a CSV file to a comment but other users are having trouble downloading it to open in excel. It looks like its opened directly as text in the browser, and there is no way to download it with the original filename. (I can right click download it with the UUID filename but that has lost the .csv extension and confuses some users)
@bobemoe
Copy link
Contributor Author

bobemoe commented Oct 24, 2019

Maybe there should be a link to download as well as a link to display/render? #6089 is displaying the attachments better, maybe this could included there?

@silverwind
Copy link
Member

Probably missing a Content-Disposition: attachment; filename="file.csv" response header on the attachment download request so browsers trigger a file download.

@bobemoe bobemoe mentioned this issue Oct 24, 2019
Closed
@bobemoe
Copy link
Contributor Author

bobemoe commented Oct 24, 2019 •
edited
Loading

Could well be missing that header. You wouldn't want it on all file types though, like images.. so would we define a list of types that do and dont, or leave it up to the end user by provided a link for both?

@guillep2k
Copy link
Member

I agree with @silverwind about the missing Content-Disposition header.

Regarding inline content (e.g. images) that get a UUID for file name, maybe the following will work without losing its inline property:

Content-Disposition: inline; filename="...."

It's a valid value, but I don't know how many browsers pick that up.

@silverwind
Copy link
Member

silverwind commented Oct 25, 2019 •
edited
Loading

I don't think inline with filename will work. Browsers will navigate to the source URL and any subsequent save functionality will use the filename from the URL supposedly. I don't see much of an issue triggering downloads for everything, at least filenames can be preserved that way.

@guillep2k
Copy link
Member

I don't think inline with filename will work. Browsers will navigate to the source URL and any subsequent save functionality will use the filename from the URL supposedly. I don't see much of an issue triggering downloads for everything, at least filenames can be preserved that way.

I've just tested with a quick .htaccess and it works better than I anticipated. It doesn't change the URL (it shouldn't), but honors the header by using the chosen file name in the save as dialog:

image

My crude .htaccess:

<Files bird.jpg>
    Header add Content-Disposition "inline; filename=\"dog.jpg\""
</Files>

So, for files with an UUID as a name, it could be useful, especially if they are inline.

I've also tested with the picture embedded in a page (which is what the inline keyword is for):

image

<!DOCTYPE html>
<html>
<head>
        <title>Bird picture</title>
</head>
<body>
        <p>Here's the inline picture of a bird:</p>
        <p><img src="bird.jpg"></p>
</body>
</html>

It works fine with the versions I've got in my PC of Firefox, Chrome, Edge and even IE.

@stale
Copy link

stale bot commented Dec 24, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale stale bot added the issue/stale label Dec 24, 2019
@lunny lunny added the issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented label Dec 25, 2019
@stale stale bot removed the issue/stale label Dec 25, 2019
@bauermarkus
Copy link

Hey
I have the same issue with an ".eml" file

@silverwind
Copy link
Member

silverwind commented Sep 23, 2022 •
edited
Loading

I think it can be solved it via browser settings, for example in Firefox under Preferences - Applications, there should be an entry for the specific type. At least in 1.18, gitea will no longe force the browser to download for certain file types, like it did before.

See #20484. You could also try to register the affected mime types in the mime map config and see if browser behaviour changes.

@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@lunny @silverwind @bobemoe @guillep2k @bauermarkus