lus / pasty

pasty is a fast and lightweight code pasting server
https://pasty.lus.pm
MIT License
200 stars 28 forks source link

Wrong Content-Type header for JavaScript file #6

Closed ReinforceZwei closed 3 years ago

ReinforceZwei commented 3 years ago

The content type header is set to text/plain in http header when requesting .js file. image

Which then causing the JavaScript not being loaded by browser. image

The following fixes has been applied for trying to solve the issue but it didn't work

        if !strings.HasPrefix(path, "/api") && (strings.Count(path, "/") == 1 || strings.HasPrefix(path, "/assets")) {
                ctx.SetContentType("")
            frontend(ctx)
            return
        }

https://github.com/lus/pasty/blob/542bb5b17d40702a41cb5bdf1eeb4aadd0d1024a/internal/web/web.go#L33-L35

OS: Windows 10 1809 Go Version: 1.16.3

ReinforceZwei commented 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
lus commented 3 years ago

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.

ReinforceZwei commented 3 years ago

This issue is platform specific I guess. Pasty on CentOS is working correctly. image

I found this issue https://github.com/valyala/fasthttp/issues/749 but seems like it was resolved.

lus commented 3 years ago

Alright, thanks for your investigation. I will implement a hotfix later today ^^

lus commented 3 years ago

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 ^^