kotx / render

Cloudflare Worker to proxy and cache requests to R2
MIT License
384 stars 85 forks source link

0-byte files cause issues #10

Closed catharsis71 closed 2 years ago

catharsis71 commented 2 years ago

maybe this is a Cloudflare issue or something but I'll mention it here

you can definitely create 0-byte files in R2 buckets

but trying to access them through your script results in odd behavior

using a HEAD request it returns a HTTP 204 (No Content) which is sensible

however using a GET request, the browser gets a HTTP 500 (Internal Server Error) along with some HTML claiming there was an error 1101

image

if I test it in the worker dashboard this is what I see:

image

kotx commented 2 years ago

Ah, seems like I need to return null as the response body if the file is 0-length. I'll look into that now.

kotx commented 2 years ago

Fixed by bb394272721148205c1521255ec1e657cbf887b7, thanks!

catharsis71 commented 2 years ago

I've been thinking about this some more

Seems like most web servers serve 0-byte files by responding with a 200 OK with a "content-length: 0". I can't speak for every web server but that's definitely how Apache does it, as well as whatever Github Pages and Cloudflare Pages are running.

Was it a conscious decision to use a 204 No Content for this or are you just getting a 204 from R2 and passing it along?

Would it make more sense to copy how most web servers behave and do it as a 200 OK / content-length: 0? With a 200 OK, you're able to actually browse to a 0-byte file and the browser will show a blank page (unless the server set the content type as application/octet-stream in which case it will treat it as a download), whereas with a 204 No Content, the browser will remain on the page it's on and it will basically seem like nothing happened (regardless of content-type).

another data point: wget will decline to write anything to disk if the server returns a 204 Not Found, whereas with a 200 OK content-length 0, it will write a 0-byte file. So if someone is using wget to spider a site with links to 0-byte files (but with potentially informative filenames), 204's will result in the site not being spidered properly as the 0-byte files won't make it onto disk.

kotx commented 2 years ago

I checked this some more and it seems like 200 is more appropriate. Also I forgot to send Content-Length it seems? I can't fix this now as I'll be busy for the next few days but if you want you can PR this, should be fairly straightforward. Sorry if it causes you any inconvenience.

kotx commented 2 years ago

I believe I've fixed this with c2f347b56ebd9f4cbd9c1ea798f53bc0d66d07ef. Let me know if anything else breaks.

catharsis71 commented 2 years ago

I had to flush my cache but yeah now it's a 200 (and now I know caching really is working)