bug(server): Invalid Content-Type for user css files #104

New issue

Closed

opened 2025-12-02 07:17:01 +00:00 by treadful · 0 comments

treadful commented

2025-12-02 07:17:01 +00:00

Owner

Server seems to be returning user CSS files with no Content-Type and probably including the file signature.

> GET /~6f03ea7/styles.css HTTP/1.1
> Host: jot.run
> User-Agent: curl/8.16.0
> Accept: text/css
> 
[...]
< HTTP/1.1 200 OK
< Server: nginx/1.28.0
< Date: Tue, 02 Dec 2025 07:17:19 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< content-security-policy: default-src 'self'; frame-src 'none'; img-src *; media-src 'none'; script-src 'none';
< 
[...css with non-utf-8 bytes trailing...]

These (and maybe some others) files should abide by the Accept header. It's also possible it needs to be set in minio upon upload. Either way, the default maybe shouldn't be the file with signature and just a plain old octet stream without signature.

Server seems to be returning user CSS files with no `Content-Type` and probably including the file signature. ``` > GET /~6f03ea7/styles.css HTTP/1.1 > Host: jot.run > User-Agent: curl/8.16.0 > Accept: text/css > [...] < HTTP/1.1 200 OK < Server: nginx/1.28.0 < Date: Tue, 02 Dec 2025 07:17:19 GMT < Transfer-Encoding: chunked < Connection: keep-alive < content-security-policy: default-src 'self'; frame-src 'none'; img-src *; media-src 'none'; script-src 'none'; < [...css with non-utf-8 bytes trailing...] ``` These (and maybe some others) files should abide by the `Accept` header. It's also possible it needs to be set in minio upon upload. Either way, the default maybe shouldn't be the file with signature and just a plain old octet stream without signature.