Closed ReinforceZwei closed 3 years ago
After playing around a bit, I am able to make a temporary working solution.
if (strings.HasSuffix(path, ".js")){
ctx.SetContentType("text/javascript");
}
frontend(ctx)
return
Hello.
Thanks for your issue.
Unfortunately, I cannot reproduce the problem you mentioned with the public instance which runs on the latest staging version:
❯ curl https://paste.pelkum.dev/assets/js/api.js -v
* Trying 167.86.109.42:443...
* Connected to paste.pelkum.dev (167.86.109.42) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=paste.pelkum.dev
* start date: Apr 12 18:30:48 2021 GMT
* expire date: Jul 11 18:30:48 2021 GMT
* subjectAltName: host "paste.pelkum.dev" matched cert's "paste.pelkum.dev"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55f9c603e920)
> GET /assets/js/api.js HTTP/2
> Host: paste.pelkum.dev
> user-agent: curl/7.76.1
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< server: nginx/1.19.3
< date: Tue, 27 Apr 2021 18:14:39 GMT
< content-type: text/javascript; charset=utf-8
< content-length: 980
< access-control-allow-methods: GET,POST,DELETE,OPTIONS
< access-control-allow-origin: *
< last-modified: Tue, 20 Apr 2021 14:40:18 GMT
< strict-transport-security: max-age=31536000
[omitted response body]
As you can see, the server responds with the correct content type.
I set up a local instance for testing purposes too and got the same response including correct content types.
This issue is platform specific I guess. Pasty on CentOS is working correctly.
I found this issue https://github.com/valyala/fasthttp/issues/749 but seems like it was resolved.
Alright, thanks for your investigation. I will implement a hotfix later today ^^
I pushed a fix to develop
which (most likely) fixes your mentioned issue.
Furthermore I will re-deploy the public instance to include this fix.
Thank you very much for your contribution ^^
The content type header is set to
text/plain
in http header when requesting.js
file.Which then causing the JavaScript not being loaded by browser.
The following fixes has been applied for trying to solve the issue but it didn't work
https://github.com/lus/pasty/blob/542bb5b17d40702a41cb5bdf1eeb4aadd0d1024a/internal/web/web.go#L33-L35
OS: Windows 10 1809 Go Version: 1.16.3