github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-07-16 13:20:06 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Cannot upload file of this type to a release (zip) #2764

New Issue
Closed
opened 2025-11-02 04:47:27 -06:00 by GiteaMirror · 30 comments
GiteaMirror commented 2025-11-02 04:47:27 -06:00
Owner
Copy Link

Originally created by @ve3 on GitHub (Jan 17, 2019).

Description

I tried to upload a file to a release but got error message "You cannot upload files of this type".
The file is zip and its mime type is application/zip.

Here is app.ini configuration.

[attachment]
ENABLED = true
PATH = D:/my-work-spaces/gitea/data/attachments
ALLOWED_TYPES = application/zip|application/x-compressed-tar|application/x-gzip
MAX_SIZE = 20
MAX_FILES = 1
Originally created by @ve3 on GitHub (Jan 17, 2019). <!-- 1. Please speak English, this is the language all of us can speak and write. 2. Please ask questions or configuration/deploy problems on our Discord server (https://discord.gg/NsatcWJ) or forum (https://discourse.gitea.io). 3. Please take a moment to check that your issue doesn't already exist. 4. Please give all relevant information below for bug reports, because incomplete details will be handled as an invalid report. --> - Gitea version (or commit ref): 1.6.3, 1.7.0, 1.7.1 - Git version: 2.20.1 - Operating system: Windows 10 x64 - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x] Yes (https://try.gitea.io/ve3/test/src/tag/0.1) - [ ] No - [ ] Not relevant ## Description I tried to upload a file to a release but got error message "You cannot upload files of this type". The file is zip and its mime type is **application/zip**. Here is app.ini configuration. ``` [attachment] ENABLED = true PATH = D:/my-work-spaces/gitea/data/attachments ALLOWED_TYPES = application/zip|application/x-compressed-tar|application/x-gzip MAX_SIZE = 20 MAX_FILES = 1 ```
GiteaMirror added the type/questionissue/confirmed labels 2025-11-02 04:47:27 -06:00
GiteaMirror commented 2025-11-02 04:47:28 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jan 17, 2019):

Have you restarted Gitea?

@lunny commented on GitHub (Jan 17, 2019): Have you restarted Gitea?
GiteaMirror commented 2025-11-02 04:47:29 -06:00
Author
Owner
Copy Link

@ve3 commented on GitHub (Jan 17, 2019):

Have you restarted Gitea?

Yes, I did.

@ve3 commented on GitHub (Jan 17, 2019): > > > Have you restarted Gitea? Yes, I did.
GiteaMirror commented 2025-11-02 04:47:29 -06:00
Author
Owner
Copy Link

@justsomebody42 commented on GitHub (Jan 28, 2019):

I have the very same issue.
Any suggestions?

@justsomebody42 commented on GitHub (Jan 28, 2019): I have the very same issue. Any suggestions?
GiteaMirror commented 2025-11-02 04:47:29 -06:00
Author
Owner
Copy Link

@uberhalit commented on GitHub (Jan 31, 2019):

Same here on latest 1.7.1, it won't let me upload zip files even though they are explicitly allowed.

Workaround: add application/x-zip-compressed to ALLOWED_TYPES

@uberhalit commented on GitHub (Jan 31, 2019): Same here on latest 1.7.1, it won't let me upload zip files even though they are explicitly allowed. **Workaround:** add `application/x-zip-compressed` to `ALLOWED_TYPES`
GiteaMirror commented 2025-11-02 04:47:30 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Feb 1, 2019):

Hmm ok so if the data gets to Gitea it will definitely be assigned a mimetype of application/zip.

This mimetype is being assigned by your browser and is being checked in dropzone. Are you using internet explorer?

Unfortunately there's not much that can be done - I think you just have to add application/x-zip-compressed either that or we have to change dropzone upstream to have a list of mapping from old non valid mimetypes to real mimetypes.

@zeripath commented on GitHub (Feb 1, 2019): Hmm ok so if the data gets to Gitea it will definitely be assigned a mimetype of application/zip. This mimetype is being assigned by your browser and is being checked in dropzone. Are you using internet explorer? Unfortunately there's not much that can be done - I think you just have to add `application/x-zip-compressed` either that or we have to change dropzone upstream to have a list of mapping from old non valid mimetypes to real mimetypes.
GiteaMirror commented 2025-11-02 04:47:30 -06:00
Author
Owner
Copy Link

@ve3 commented on GitHub (Feb 1, 2019):

I'm using Firefox.
Added application/zip|application/x-zip|application/x-zip-compressed|application/x-compress|application/x-compressed|multipart/x-zip (copied from https://filext.com/file-extension/ZIP ) but still does not work.

Of cause, I'm already restarted Gitea.

Gitea 1.7.0

@ve3 commented on GitHub (Feb 1, 2019): I'm using Firefox. Added `application/zip|application/x-zip|application/x-zip-compressed|application/x-compress|application/x-compressed|multipart/x-zip` (copied from https://filext.com/file-extension/ZIP ) but still does not work. Of cause, I'm already restarted Gitea. Gitea 1.7.0
GiteaMirror commented 2025-11-02 04:47:30 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Feb 1, 2019):

Are you running Gitea behind an nginx proxy? If so you will need to allow nginx to allow it too

@zeripath commented on GitHub (Feb 1, 2019): Are you running Gitea behind an nginx proxy? If so you will need to allow nginx to allow it too
GiteaMirror commented 2025-11-02 04:47:30 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Feb 1, 2019):

Ok, here's where I think that's being set:
801843b011/public/vendor/plugins/dropzone/dropzone.js (L953)

@zeripath commented on GitHub (Feb 1, 2019): Ok, here's where I think that's being set: https://github.com/go-gitea/gitea/blob/801843b0115e29ba2304fa6a5bea1ae169a58e02/public/vendor/plugins/dropzone/dropzone.js#L953
GiteaMirror commented 2025-11-02 04:47:31 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Feb 1, 2019):

If you're not running an nginx proxy then I think this is something to do with your browser - I am really not sure that this is even getting to the Gitea server and I think your upload is being rejected by dropzone.

801843b011/public/vendor/plugins/dropzone/dropzone.js (L1583)

This is on your browser so you should be able to double check what it's seeing by sticking breakpoints in in the developer console.

@zeripath commented on GitHub (Feb 1, 2019): If you're not running an nginx proxy then I think this is something to do with your browser - I am really not sure that this is even getting to the Gitea server and I think your upload is being rejected by dropzone. https://github.com/go-gitea/gitea/blob/801843b0115e29ba2304fa6a5bea1ae169a58e02/public/vendor/plugins/dropzone/dropzone.js#L1583 This is on your browser so you should be able to double check what it's seeing by sticking breakpoints in in the developer console.
GiteaMirror commented 2025-11-02 04:47:31 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Apr 2, 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[bot] commented on GitHub (Apr 2, 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.
GiteaMirror commented 2025-11-02 04:47:32 -06:00
Author
Owner
Copy Link

@ve3 commented on GitHub (Apr 4, 2019):

I don't running nginx proxy. This problem even occur on https://try.gitea.io
As the link I provided https://try.gitea.io/ve3/test/src/tag/0.1

I'm not sure did you tried to upload .zip on your server ( https://try.gitea.io ) because it same and it is not just my browser problem.

@ve3 commented on GitHub (Apr 4, 2019): I don't running nginx proxy. This problem even occur on https://try.gitea.io As the link I provided https://try.gitea.io/ve3/test/src/tag/0.1 I'm not sure did you tried to upload .zip on your server ( https://try.gitea.io ) because it same and it is not just my browser problem.
GiteaMirror commented 2025-11-02 04:47:32 -06:00
Author
Owner
Copy Link

@mrsdizzie commented on GitHub (Apr 4, 2019):

This worked fine for me on try.gitea.io just now:

https://try.gitea.io/mrsdizzie/parsing-errors/releases

That sshot.zip attachment has a mime-type of application/zip same as mentioned in the issue report.

The link you've provided to try.gitea.io unfortunately doesn't help because of the nature of the problem (there is no file there for anybody to look at). Is it possible to share an example zip file that doesn't work right for you? Being able to reproduce will help track down what may be happening (can't reproduce it with my own application/zip file)

@mrsdizzie commented on GitHub (Apr 4, 2019): This worked fine for me on try.gitea.io just now: https://try.gitea.io/mrsdizzie/parsing-errors/releases That sshot.zip attachment has a mime-type of ``` application/zip``` same as mentioned in the issue report. The link you've provided to try.gitea.io unfortunately doesn't help because of the nature of the problem (there is no file there for anybody to look at). Is it possible to share an example zip file that doesn't work right for you? Being able to reproduce will help track down what may be happening (can't reproduce it with my own application/zip file)
GiteaMirror commented 2025-11-02 04:47:32 -06:00
Author
Owner
Copy Link

@ve3 commented on GitHub (Apr 4, 2019):

https://try.gitea.io/ve3/test/releases

Download (ZIP) from there
Edit release
Upload the zip file
Failed.

All the zip files cannot upload.

This seems to be only happens with Firefox on Windows (not sure Firefox on other os).

@ve3 commented on GitHub (Apr 4, 2019): https://try.gitea.io/ve3/test/releases Download (ZIP) from there Edit release Upload the zip file Failed. All the zip files cannot upload. This seems to be only happens with Firefox on Windows (not sure Firefox on other os).
GiteaMirror commented 2025-11-02 04:47:33 -06:00
Author
Owner
Copy Link

@mrsdizzie commented on GitHub (Apr 4, 2019):

I was just able to download that zip file, edit the release in my example, and the upload it fine:

https://try.gitea.io/mrsdizzie/parsing-errors/releases

It works on Safari, Chrome, and Firefox on macOS.

Can't reproduce with any of the current suggest steps here on my end unfortunately :( Sounds like perhaps a Firefox on Windows bug.

@mrsdizzie commented on GitHub (Apr 4, 2019): I was just able to download that zip file, edit the release in my example, and the upload it fine: https://try.gitea.io/mrsdizzie/parsing-errors/releases It works on Safari, Chrome, and Firefox on macOS. Can't reproduce with any of the current suggest steps here on my end unfortunately :( Sounds like perhaps a Firefox on Windows bug.
GiteaMirror commented 2025-11-02 04:47:33 -06:00
Author
Owner
Copy Link

@mrsdizzie commented on GitHub (Apr 5, 2019):

Also FWIW some searching suggests this might be related to problems with the files Firefox uses to store mime-type information and starting over with a fresh profile seems to help many people having trouble uploading to different sites.

@mrsdizzie commented on GitHub (Apr 5, 2019): Also FWIW some searching suggests this might be related to problems with the files Firefox uses to store mime-type information and starting over with a fresh profile seems to help many people having trouble uploading to different sites.
GiteaMirror commented 2025-11-02 04:47:33 -06:00
Author
Owner
Copy Link

@efelon commented on GitHub (Apr 5, 2019):

gitea 1.7.5 armv7
on raspbian stretch
Browser chromium on Linux Mint

I wanted to add an observation, because I was curious if there is nothing in the logs about blocked mime-types, so one could just easily add them gitea kindly detected.

ALLOWED_TYPES=application/zip

With this attaching zip files is possible on my installation. Then I did:
Modified app.ini: LEVEL = Trace && service gitea restart

After restart I tried to upload a tar.gz file, and to my surprise in gitea.log I got:
2019/04/05 20:55:27 [I] Attachment with type application/x-gzip blocked from upload

Easy enough, went ahead and added that mime type + restart of gitea.

ALLOWED_TYPES=application/zip|application/x-gzip

Uploading of tar.gz files still didn't work. So...long story short,
I never got a blocked entry in my logs after that again.

I restarted multiple times, reverted the ALLOWED_TYPES, changed ALLOWED_TYPES, changed LEVEL back and forth, logged in/out, changed user and multiple combinations of that. I never got a blocked entry in gitea.log again.

@efelon commented on GitHub (Apr 5, 2019): gitea 1.7.5 armv7 on raspbian stretch Browser chromium on Linux Mint I wanted to add an observation, because I was curious if there is nothing in the logs about blocked mime-types, so one could just easily add them gitea kindly detected. > ALLOWED_TYPES=application/zip With this attaching zip files is possible on my installation. Then I did: `Modified app.ini: LEVEL = Trace && service gitea restart` After restart I tried to upload a tar.gz file, and to my surprise in **gitea.log** I got: `2019/04/05 20:55:27 [I] Attachment with type application/x-gzip blocked from upload` Easy enough, went ahead and added that mime type + restart of gitea. > ALLOWED_TYPES=application/zip|application/x-gzip Uploading of tar.gz files **still didn't work**. So...long story short, **I never got a blocked entry in my logs after that again.** I restarted multiple times, reverted the ALLOWED_TYPES, changed ALLOWED_TYPES, changed LEVEL back and forth, logged in/out, changed user and multiple combinations of that. I never got a blocked entry in gitea.log again.
GiteaMirror commented 2025-11-02 04:47:34 -06:00
Author
Owner
Copy Link

@dheadshot commented on GitHub (May 12, 2019):

I've just encountered this infuriating bug as a user of the showcase instance gitea.com - I created an account there to try and get away from this kind of nonsense on Github!

@dheadshot commented on GitHub (May 12, 2019): I've just encountered this infuriating bug as a user of the showcase instance gitea.com - I created an account there to try and get away from this kind of nonsense on Github!
GiteaMirror commented 2025-11-02 04:47:34 -06:00
Author
Owner
Copy Link

@ve3 commented on GitHub (May 28, 2019):

From try.gitea.io server, I tried to upload fake .jpg file.
I created fake .jpg file with .txt file. (new > text file > rename fake-image.jpg).
I try to select a file > success, the file was sent to server via XHR but the response is failed. Error 400 with message:

File type is not allowed

This issue stuck at select a file and then failed. It is not even upload yet.

My browser (Firefox on Windows) have no problem with normal upload HTML form with PHP, ASP.net, or any other programming languages on earth.
They can detect the real file's mime type correctly.

So, this problem should be fixed easily if we skip the check mime type part that is currently using JS and let it check with the server instead.
The server already do that (check mime type), doing this with JS is not necessary.

Edit:
This also happens with MS Edge. ( https://stackoverflow.com/q/32849014/128761 ). I'm not sure that Firefox, IE, and Edge use the same mime type data source but they both cant get JS input files[0].type.

Here is the source code to test get file's mime type from browser input.

<form enctype="multipart/form-data">
<input type="file" multiple="multiple" class="dz-hidden-input" accept="image/jpeg,image/png,application/zip,application/gzip">
<button type="submit">Upload</button>
</form>

<div class="debug"></div>

<script src="https://code.jquery.com/jquery-3.4.1.min.js"></script>
<script>
    $(document).ready(function() {
        $('.dz-hidden-input').on('change', function(e) {
            console.log(this.files[0].type);
            $('.debug').append('<br> - ' + this.files[0].type);
        });
    });
</script>

Failed: IE, Firefox, Edge

@ve3 commented on GitHub (May 28, 2019): From try.gitea.io server, I tried to upload fake .jpg file. I created fake .jpg file with .txt file. (new > text file > rename fake-image.jpg). I try to select a file > success, the file was sent to server via XHR but the response is failed. Error 400 with message: > File type is not allowed This issue stuck at select a file and then failed. It is not even upload yet. My browser (Firefox on Windows) have no problem with **normal** upload HTML form **with** PHP, ASP.net, or any other programming languages on earth. They can detect the real file's mime type correctly. So, this problem should be fixed easily if we skip the check mime type part that is currently using JS and let it check with the server instead. The server already do that (check mime type), doing this with JS is not necessary. Edit: This also happens with MS Edge. ( https://stackoverflow.com/q/32849014/128761 ). I'm not sure that Firefox, IE, and Edge use the same mime type data source but they both cant get JS input `files[0].type`. Here is the source code to test get file's mime type from browser input. ``` <form enctype="multipart/form-data"> <input type="file" multiple="multiple" class="dz-hidden-input" accept="image/jpeg,image/png,application/zip,application/gzip"> <button type="submit">Upload</button> </form> <div class="debug"></div> <script src="https://code.jquery.com/jquery-3.4.1.min.js"></script> <script> $(document).ready(function() { $('.dz-hidden-input').on('change', function(e) { console.log(this.files[0].type); $('.debug').append('<br> - ' + this.files[0].type); }); }); </script> ``` Failed: IE, Firefox, Edge
GiteaMirror commented 2025-11-02 04:47:35 -06:00
Author
Owner
Copy Link

@ashimokawa commented on GitHub (Jun 10, 2019):

Easy enough, went ahead and added that mime type + restart of gitea.

ALLOWED_TYPES=application/zip|application/x-gzip

Uploading of tar.gz files still didn't work. So...long story short,
I never got a blocked entry in my logs after that again.

I did exactly that change on https://codeberg.org and it works there now 🤷‍♂️

@ashimokawa commented on GitHub (Jun 10, 2019): > Easy enough, went ahead and added that mime type + restart of gitea. > > > ALLOWED_TYPES=application/zip|application/x-gzip > > Uploading of tar.gz files **still didn't work**. So...long story short, > **I never got a blocked entry in my logs after that again.** I did exactly that change on https://codeberg.org and it works there now :man_shrugging:
GiteaMirror commented 2025-11-02 04:47:35 -06:00
Author
Owner
Copy Link

@ve3 commented on GitHub (Jun 10, 2019):

As I said, verify mime type using JS is based on browser and it is too much various causes (OS, browser, version on both OS & browser, etc).
Remove the JS mime type verification and let this task done by the server side to give it one standard.

@ve3 commented on GitHub (Jun 10, 2019): As I said, verify mime type using JS is based on browser and it is too much various causes (OS, browser, version on both OS & browser, etc). Remove the JS mime type verification and let this task done by the server side to give it one standard.
GiteaMirror commented 2025-11-02 04:47:36 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Aug 9, 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[bot] commented on GitHub (Aug 9, 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.
GiteaMirror commented 2025-11-02 04:47:36 -06:00
Author
Owner
Copy Link

@JAD-SVK commented on GitHub (Aug 16, 2019):

I got today the same problem. I tried drag&drop and upload by clicking (file open dialogue).

My parameter are like this:

  • Gitea version: 1.9.1
  • Git version: 2.22.0.windows.1
  • Operating system: (PC A) Windows 7 + Vivaldi 2.6.1566.49 x64 / Firefox 68.0.2 (64-bit) on web version; (PC B) Windows 10 + Vivaldi 2.6.1566.49 x64 on local machine
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:

This setting helped for me:

[attachment]
ENABLED = true
PATH = ./data/attachments
ALLOWED_TYPES = application/zip|application/x-zip|application/x-compressed-tar|application/x-compressed|application/x-gzip|application/x-compress|application/x-zip-compressed|multipart/x-zip
MAX_SIZE = 20
MAX_FILES = 5

TestZipFile.zip

File: TestZipFile.txt
Content: This file is test file + new line (CR+LF)
Zipped using 7z version 19.00

@JAD-SVK commented on GitHub (Aug 16, 2019): I got today the same problem. I tried drag&drop and upload by clicking (file open dialogue). My parameter are like this: - Gitea version: 1.9.1 - Git version: 2.22.0.windows.1 - Operating system: (PC A) Windows 7 + Vivaldi 2.6.1566.49 x64 / Firefox 68.0.2 (64-bit) on web version; (PC B) Windows 10 + Vivaldi 2.6.1566.49 x64 on local machine - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x] Yes (https://try.gitea.io/JAD-SVK/UploadTest/releases) - [ ] No - [ ] Not relevant This setting helped for me: ``` [attachment] ENABLED = true PATH = ./data/attachments ALLOWED_TYPES = application/zip|application/x-zip|application/x-compressed-tar|application/x-compressed|application/x-gzip|application/x-compress|application/x-zip-compressed|multipart/x-zip MAX_SIZE = 20 MAX_FILES = 5 ``` [TestZipFile.zip](https://github.com/go-gitea/gitea/files/3509968/TestZipFile.zip) File: `TestZipFile.txt` Content: `This file is test file` + new line (CR+LF) Zipped using 7z version 19.00
GiteaMirror commented 2025-11-02 04:47:36 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Aug 16, 2019):

For release, you should change repository.upload section not attachment

[repository.upload]
ALLOWED_TYPES = "application/zip|application/gzip|application/x-gzip|application/x-gtar|application/x-tgz|application/x-compressed-tar|text/plain"

[attachment]
ALLOWED_TYPES = "application/zip|application/gzip|application/x-gzip|application/x-gtar|application/x-tgz|application/x-compressed-tar|text/plain"
@lunny commented on GitHub (Aug 16, 2019): For release, you should change `repository.upload` section not `attachment` ```ini [repository.upload] ALLOWED_TYPES = "application/zip|application/gzip|application/x-gzip|application/x-gtar|application/x-tgz|application/x-compressed-tar|text/plain" [attachment] ALLOWED_TYPES = "application/zip|application/gzip|application/x-gzip|application/x-gtar|application/x-tgz|application/x-compressed-tar|text/plain" ```
GiteaMirror commented 2025-11-02 04:47:37 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Aug 16, 2019):

Please confirm @ve3 @JAD-SVK

@lunny commented on GitHub (Aug 16, 2019): Please confirm @ve3 @JAD-SVK
GiteaMirror commented 2025-11-02 04:47:37 -06:00
Author
Owner
Copy Link

@JAD-SVK commented on GitHub (Aug 16, 2019):

I need to add (configure)

[attachment]
ALLOWED_TYPES = application/zip|application/x-zip-compressed

To be able to upload zip files (from Vivaldi and Firefox on Windows 7) to release. Both types need to be active.

No configuration in [repository.upload] make the upload in release work.

@JAD-SVK commented on GitHub (Aug 16, 2019): I need to add (configure) ``` [attachment] ALLOWED_TYPES = application/zip|application/x-zip-compressed ``` To be able to upload zip files (from Vivaldi and Firefox on Windows 7) to release. Both types need to be active. No configuration in `[repository.upload]` make the upload in release work.
GiteaMirror commented 2025-11-02 04:47:37 -06:00
Author
Owner
Copy Link

@ve3 commented on GitHub (Aug 16, 2019):

@lunny Yes, but I must add both [repository.upload] AND [attachment] the same ALLOWED_TYPES to make it work properly. Not just [repository.upload] OR [attachment]

Full config example (about upload):

[repository.upload]
ALLOWED_TYPES = application/zip|application/x-zip|application/x-zip-compressed|application/x-compress|application/x-compressed|multipart/x-zip

[attachment]
ENABLED       = true
PATH          = E:/my-work-spaces/Gitea/data/attachments
ALLOWED_TYPES = application/zip|application/x-zip|application/x-zip-compressed|application/x-compress|application/x-compressed|multipart/x-zip
MAX_SIZE      = 20
MAX_FILES     = 1

The configuration [repository.upload] is not in anywhere in the document currently.
( https://docs.gitea.io/en-us/config-cheat-sheet/ )

Problem seems to be resolved now.

However please consider my idea about file mime type verification only in one side (server side). To check mime type on client side (JS) can be a mess and duplicate task.

@ve3 commented on GitHub (Aug 16, 2019): @lunny Yes, but I must add **both** `[repository.upload]` AND `[attachment]` the same `ALLOWED_TYPES` to make it work properly. Not just `[repository.upload]` OR `[attachment]` Full config example (about upload): ``` [repository.upload] ALLOWED_TYPES = application/zip|application/x-zip|application/x-zip-compressed|application/x-compress|application/x-compressed|multipart/x-zip [attachment] ENABLED = true PATH = E:/my-work-spaces/Gitea/data/attachments ALLOWED_TYPES = application/zip|application/x-zip|application/x-zip-compressed|application/x-compress|application/x-compressed|multipart/x-zip MAX_SIZE = 20 MAX_FILES = 1 ``` The configuration `[repository.upload]` is not in anywhere in the document currently. ( https://docs.gitea.io/en-us/config-cheat-sheet/ ) Problem seems to be resolved now. However please consider my idea about file mime type verification only in one side (server side). To check mime type on client side (JS) can be a mess and duplicate task.
GiteaMirror commented 2025-11-02 04:47:37 -06:00
Author
Owner
Copy Link

@memstone commented on GitHub (Sep 10, 2019):

ALLOWED_TYPES = application/zip|application/x-zip|application/x-compressed-tar|application/x-compressed|application/x-gzip|application/x-compress|application/x-zip-compressed|multipart/x-zip

This is work for me. thanks.

@memstone commented on GitHub (Sep 10, 2019): > ALLOWED_TYPES = application/zip|application/x-zip|application/x-compressed-tar|application/x-compressed|application/x-gzip|application/x-compress|application/x-zip-compressed|multipart/x-zip This is work for me. thanks.
GiteaMirror commented 2025-11-02 04:47:38 -06:00
Author
Owner
Copy Link

@DailytheNoob commented on GitHub (Feb 6, 2020):

I've followed the steps above (added to repository.upload & attachment) but am still unable to upload a .zip with the same error message.

@DailytheNoob commented on GitHub (Feb 6, 2020): I've followed the steps above (added to `repository.upload` & `attachment`) but am still unable to upload a .zip with the same error message.
GiteaMirror commented 2025-11-02 04:47:38 -06:00
Author
Owner
Copy Link

@iamdoubz commented on GitHub (Sep 17, 2020):

So, I got the .zip to work, now I just need the .7z to work as well...

@iamdoubz commented on GitHub (Sep 17, 2020): So, I got the .zip to work, now I just need the .7z to work as well...
GiteaMirror commented 2025-11-02 04:47:38 -06:00
Author
Owner
Copy Link

@sglux commented on GitHub (Nov 11, 2020):

regarding 7z, adding application/x-7z-compressed did not work for me.
Above mime type is from mozilla.org - maybe it must be different?

Perheps a few usual file type should be in the default app.ini file!

@sglux commented on GitHub (Nov 11, 2020): regarding 7z, adding `application/x-7z-compressed` did not work for me. Above mime type is from mozilla.org - maybe it must be different? Perheps a few usual file type should be in the default app.ini file!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/confirmed type/question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#2764
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?