Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filename requested by browser differs from the real filename on a file system. #2

Closed
koorchik opened this issue Oct 21, 2013 · 7 comments

Comments

@koorchik
Copy link

I would like to serve static files with nginx but filename that was requested by browser and filename in "public/packed" directory are different.

Steps to reproduce:

  1. I configure nginx to serve static files from "public" dir.
  2. I start hypnotoad and open my application in a browser. In HTML we will have something like
    <script src="/packed/app.1379243728.js">.
  3. Browser will ask server(nginx) for file but nginx will return 404 error because real file name on filesystem is "/packed/app.js" (without timestamp).

I guess that we have name without timestamp to avoid "packed" directory cleaning from old files. Especially when we are working under morbo (we will have a new packed file after each morbo restart). So, it would be nice to have an option for plugin (to store files with timestamp).

Also l would like suggest to use md5 sum instead of timestamp. In this case browser will not reload all packed files after each hypnotoad restart(often we have updates without JS/CSS changes)

@jhthorsen
Copy link
Member

I wouldn't mind taking a patch where we use md5 instead of timetamp, but I'm pretty sure I won't take a patch where the requested file match the file on the filesystem. Why? Because browsers have pretty messed up caching logic, so the only way I can know for sure that they download the new version is by renaming the requested file.

I'm suggesting you reconfigure nginx to cache the document served, instead of serving a static file. I really think making nginx serve files that mojo should serve is broken.

Something like this: http://techminded.net/blog/transparent-cache-in-nginx.html

@koorchik
Copy link
Author

Because browsers have pretty messed up caching logic, so the only way I can know for sure that they download the new version is by renaming the requested file.

Yes, absolutly! Therefore, I absolutly agree that file should have a new name after regeneration. But the plugin saves the file under the same name after regenerating. I mean, that file does not contain timestamp.

@jhthorsen
Copy link
Member

So you want the generator to create a file on disk with the md5 sum included in the filename? That might actually make sense! Let me think about it.

Any plans on actually making a patch, or will you leave that up to someone else/me?

@jhthorsen jhthorsen reopened this Oct 25, 2013
@koorchik
Copy link
Author

So you want the generator to create a file on disk with the md5 sum included in the filename?

Yep

Any plans on actually making a patch, or will you leave that up to someone else/me?

I guess your implementation will be much higher quality than mine as you are the plugin's author :)

@jhthorsen
Copy link
Member

Could you check out my new version? Check the diff listed above and let me know what you think. All tests pass, so it should be good to go.

I'm thinking about doing substr($md5, 0, 8). I think it's more than safe enough. Comment?

@koorchik
Copy link
Author

Thanks a lot. Looks good.

I'm thinking about doing substr($md5, 0, 8). I think it's more than safe enough. Comment?

I think It will be overkill :). I think it is just better to replace md5 matching. Use $md5_re = qr/[0-9ae]{32}/i instead of \w{32}

@jhthorsen
Copy link
Member

Enjoy :)

jhthorsen pushed a commit that referenced this issue May 8, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants