serviceworker.js failed to register (on windows) #8386

New Issue

GiteaMirror · 2025-11-02T08:04:29-06:00

GiteaMirror commented

2025-11-02 08:04:29 -06:00

Originally created by @snoopydo on GitHub (Jan 20, 2022).

Gitea Version

1.16.0-rc1

Git Version

git version 2.34.1.windows.1

Operating System

Windows 10 21H1 (build 19043.1466)

How are you running Gitea?

Downloaded gitea-1.16.0-rc1-gogit-windows-4.0-amd64.exe from the github releases page.
stopped windows service
Copied over top to replace existing gitea.exe
restarted windows service

Database

MSSQL

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Description

In edge & chrome, the serviceworker.js fails to install with an error logged to the console.

DOMException: Failed to register a ServiceWorker for scope ('http://localhost:3000/assets/') with script ('http://localhost:3000/assets/serviceworker.js'): The script has an unsupported MIME type ('text/plain').

First appeared when i installed version 1.15.10

Screenshots

No response

Originally created by @snoopydo on GitHub (Jan 20, 2022). ### Gitea Version 1.16.0-rc1 ### Git Version git version 2.34.1.windows.1 ### Operating System Windows 10 21H1 (build 19043.1466) ### How are you running Gitea? Downloaded gitea-1.16.0-rc1-gogit-windows-4.0-amd64.exe from the github releases page. stopped windows service Copied over top to replace existing gitea.exe restarted windows service ### Database MSSQL ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Description In edge & chrome, the serviceworker.js fails to install with an error logged to the console. DOMException: Failed to register a ServiceWorker for scope ('http://localhost:3000/assets/') with script ('http://localhost:3000/assets/serviceworker.js'): The script has an unsupported MIME type ('text/plain'). First appeared when i installed version 1.15.10 ### Screenshots _No response_

GiteaMirror closed this issue

2025-11-02 08:04:29 -06:00

GiteaMirror commented

2025-11-02 08:04:29 -06:00

@zeripath commented on GitHub (Jan 20, 2022):

This is a common problem with cached out of date service workers. Forcibly reload the page and/or clear the serviceworker out.

@zeripath commented on GitHub (Jan 20, 2022): This is a common problem with cached out of date service workers. Forcibly reload the page and/or clear the serviceworker out.

GiteaMirror commented

2025-11-02 08:04:30 -06:00

@snoopydo commented on GitHub (Jan 21, 2022):

Did all that the straight away after installing 1.15.10, gave it a few days still no joy, then tried the RC and still no luck. Using fiddler, gitea is returning the serviceworker.js with content type text/plain

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: private, max-age=21600
Content-Length: 21208
Content-Type: text/plain; charset=utf-8
Etag: "MjEyMDhzZXJ2aWNld29ya2VyLmpzVGh1LCAyMCBKYW4gMjAyMiAyMTowMzo1NiBHTVQ="
Last-Modified: Thu, 20 Jan 2022 21:03:56 GMT
Date: Fri, 21 Jan 2022 00:15:43 GMT

@snoopydo commented on GitHub (Jan 21, 2022): Did all that the straight away after installing 1.15.10, gave it a few days still no joy, then tried the RC and still no luck. Using fiddler, gitea is returning the serviceworker.js with content type text/plain ```` HTTP/1.1 200 OK Accept-Ranges: bytes Cache-Control: private, max-age=21600 Content-Length: 21208 Content-Type: text/plain; charset=utf-8 Etag: "MjEyMDhzZXJ2aWNld29ya2VyLmpzVGh1LCAyMCBKYW4gMjAyMiAyMTowMzo1NiBHTVQ=" Last-Modified: Thu, 20 Jan 2022 21:03:56 GMT Date: Fri, 21 Jan 2022 00:15:43 GMT ````

GiteaMirror commented

2025-11-02 08:04:30 -06:00

@wxiaoguang commented on GitHub (Jan 21, 2022):

Hmm .... My Linux reports:

< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Cache-Control: private, max-age=300
< Content-Length: 21208
< Content-Type: text/javascript; charset=utf-8
< Etag: "MjEyMDhzZXJ2aWNld29ya2VyLmpzRnJpLCAyMSBKYW4gMjAyMiAwMzo1NjoxOCBHTVQ="
< Last-Modified: Fri, 21 Jan 2022 03:56:18 GMT
< Date: Fri, 21 Jan 2022 04:22:48 GMT

So the Content-Length/Etag is the same, I believe they are the same file. But the Content-Type is different.

And since you are accessing http://localhost:3000/assets/serviceworker.js directly, it is the response from Gitea directly.

~~Maybe something wrong with the Windows build.~~

However, I can not reproduce your problem.

@wxiaoguang commented on GitHub (Jan 21, 2022): Hmm .... My Linux reports: ``` < HTTP/1.1 200 OK < Accept-Ranges: bytes < Cache-Control: private, max-age=300 < Content-Length: 21208 < Content-Type: text/javascript; charset=utf-8 < Etag: "MjEyMDhzZXJ2aWNld29ya2VyLmpzRnJpLCAyMSBKYW4gMjAyMiAwMzo1NjoxOCBHTVQ=" < Last-Modified: Fri, 21 Jan 2022 03:56:18 GMT < Date: Fri, 21 Jan 2022 04:22:48 GMT ``` So the Content-Length/Etag is the same, I believe they are the same file. But the Content-Type is different. And since you are accessing `http://localhost:3000/assets/serviceworker.js` directly, it is the response from Gitea directly. ~~Maybe something wrong with the Windows build.~~ However, I can not reproduce your problem.

GiteaMirror commented

2025-11-02 08:04:30 -06:00

@wxiaoguang commented on GitHub (Jan 21, 2022):

However, I can not reproduce your problem:

I downloaded the gitea-1.16.0-rc1-gogit-windows-4.0-amd64.exe and run it in Windows,

The response of http://localhost:3000/assets/serviceworker.js is:

Accept-Ranges: bytes
Cache-Control: private, max-age=21600
Content-Encoding: gzip
Content-Type: text/javascript; charset=utf-8
Date: Fri, 21 Jan 2022 04:29:37 GMT
Etag: "MjEyMDhzZXJ2aWNld29ya2VyLmpzRnJpLCAyMSBKYW4gMjAyMiAwNDoyNzozMyBHTVQ="
Last-Modified: Fri, 21 Jan 2022 04:27:33 GMT
Transfer-Encoding: chunked

Everything seems fine. Do you have more clues?

@wxiaoguang commented on GitHub (Jan 21, 2022): However, I can not reproduce your problem: I downloaded the `gitea-1.16.0-rc1-gogit-windows-4.0-amd64.exe` and run it in Windows, The response of `http://localhost:3000/assets/serviceworker.js` is: ``` Accept-Ranges: bytes Cache-Control: private, max-age=21600 Content-Encoding: gzip Content-Type: text/javascript; charset=utf-8 Date: Fri, 21 Jan 2022 04:29:37 GMT Etag: "MjEyMDhzZXJ2aWNld29ya2VyLmpzRnJpLCAyMSBKYW4gMjAyMiAwNDoyNzozMyBHTVQ=" Last-Modified: Fri, 21 Jan 2022 04:27:33 GMT Transfer-Encoding: chunked ``` Everything seems fine. Do you have more clues?

GiteaMirror commented

2025-11-02 08:04:30 -06:00

@silverwind commented on GitHub (Jan 21, 2022):

Is it only this one JS file that returns wrong mime type or the others as well?

@silverwind commented on GitHub (Jan 21, 2022): Is it only this one JS file that returns wrong mime type or the others as well?

GiteaMirror commented

2025-11-02 08:04:30 -06:00

@snoopydo commented on GitHub (Jan 22, 2022):

No clues as to what might cause the change to content type for the serviceworker.js file, version 1.15.10 returns the correct content type.

serviceworker.js is the only file that has the wrong content type.

@snoopydo commented on GitHub (Jan 22, 2022): No clues as to what might cause the change to content type for the serviceworker.js file, version 1.15.10 returns the correct content type. serviceworker.js is the only file that has the wrong content type.

GiteaMirror commented

2025-11-02 08:04:30 -06:00

@wxiaoguang commented on GitHub (Jan 22, 2022):

// TypeByExtension returns the MIME type associated with the file extension ext.
// The extension ext should begin with a leading dot, as in ".html".
// When ext has no associated type, TypeByExtension returns "".
//
// Extensions are looked up first case-sensitively, then case-insensitively.
//
// On Windows, MIME types are extracted from the registry.
//
// Text types have the charset parameter set to "utf-8" by default.
func TypeByExtension(ext string) string {

Is your Windows registry correct? Does it contains correct .js mime-type?

@wxiaoguang commented on GitHub (Jan 22, 2022): ``` // TypeByExtension returns the MIME type associated with the file extension ext. // The extension ext should begin with a leading dot, as in ".html". // When ext has no associated type, TypeByExtension returns "". // // Extensions are looked up first case-sensitively, then case-insensitively. // // On Windows, MIME types are extracted from the registry. // // Text types have the charset parameter set to "utf-8" by default. func TypeByExtension(ext string) string { ``` Is your Windows registry correct? Does it contains correct `.js` mime-type?

GiteaMirror commented

2025-11-02 08:04:31 -06:00

@silverwind commented on GitHub (Jan 22, 2022):

We should probably not rely on registry in TypeByExtension and at least hardcode the JS/CSS/HTML/PNG etc. mime types. Thought I don't think this will solve OPs issue where only this one file is affected.

@silverwind commented on GitHub (Jan 22, 2022): We should probably not rely on registry in `TypeByExtension` and at least hardcode the JS/CSS/HTML/PNG etc. mime types. Thought I don't think this will solve OPs issue where only this one file is affected.

GiteaMirror commented

2025-11-02 08:04:31 -06:00

@snoopydo commented on GitHub (Jan 23, 2022):

Ok, done some digging in the windows registry.
Windows 10 computers all have text/plain as content type
Windows Servers have NO content type key at all.

[edit] all our computers/servers are standard installs with no customisation done other than installing IIS etc

@snoopydo commented on GitHub (Jan 23, 2022): Ok, done some digging in the windows registry. Windows 10 computers all have text/plain as content type Windows Servers have NO content type key at all. [edit] all our computers/servers are standard installs with no customisation done other than installing IIS etc

GiteaMirror commented

2025-11-02 08:04:31 -06:00

@wxiaoguang commented on GitHub (Jan 23, 2022):

Ok, done some digging in the windows registry. Windows 10 computers all have text/plain as content type Windows Servers have NO content type key at all.

[edit] all our computers/servers are standard installs with no customisation done other than installing IIS etc

Do you have conclusions? Is your clue related to this issue? Golang's mime detector seems to work like this: there are some built-in mime-types (including .js), but if Golang can read OS's mime type config, then Golang will use OS's mime type config to overwrite the built-in.

@wxiaoguang commented on GitHub (Jan 23, 2022): > Ok, done some digging in the windows registry. Windows 10 computers all have text/plain as content type Windows Servers have NO content type key at all. > > [edit] all our computers/servers are standard installs with no customisation done other than installing IIS etc Do you have conclusions? Is your clue related to this issue? Golang's mime detector seems to work like this: there are some built-in mime-types (including `.js`), but if Golang can read OS's mime type config, then Golang will use OS's mime type config to overwrite the built-in.

GiteaMirror commented

2025-11-02 08:04:31 -06:00

@snoopydo commented on GitHub (Jan 23, 2022):

Given the registry entries and how you describe the golang mime handling works, the text/plain is expected, i assume on the servers because there is no entry, there is a internal fallback that is used.

I guess this means gitea is working as expected given the environment and this is a golang mime issue regarding the handling of windows and its broken defaults.

This can be closed if you like, it doesn't appear to be a fault of gitea.

@snoopydo commented on GitHub (Jan 23, 2022): Given the registry entries and how you describe the golang mime handling works, the text/plain is expected, i assume on the servers because there is no entry, there is a internal fallback that is used. I guess this means gitea is working as expected given the environment and this is a golang mime issue regarding the handling of windows and its broken defaults. This can be closed if you like, it doesn't appear to be a fault of gitea.

GiteaMirror commented

2025-11-02 08:04:32 -06:00

@wxiaoguang commented on GitHub (Jan 23, 2022):

Although it explains the issue, but I think how Golang handle mime types is not ideal (especially for Gitea HTTP server).

I would like to propose a PR to make Gitea treat all well-known extensions as hard-coded mime-types to bypass the OS config.

Please leave this issue open.

@wxiaoguang commented on GitHub (Jan 23, 2022): Although it explains the issue, but I think how Golang handle mime types is not ideal (especially for Gitea HTTP server). I would like to propose a PR to make Gitea treat all well-known extensions as hard-coded mime-types to bypass the OS config. Please leave this issue open.

GiteaMirror commented

2025-11-02 08:04:32 -06:00

@wxiaoguang commented on GitHub (Jan 23, 2022):

I proposed a fix: