-
Notifications
You must be signed in to change notification settings - Fork 0
put everything in a static directory #3
put everything in a static directory #3
Conversation
Tested by deleting everything, running npm install from scratch. This helps ensure that only the files in the static subdirectory can be served. Should eliminate serving config files via http.
|
Would you mind testing this as well. Everything looks good here, but I gave it a very very quick review. |
move static files into /static
|
The bower_components folder did not get moved into /static. I manually moved it and it works, but something is off. I see bower_components is listed in .gitignore. |
|
Hmm did you run npm install? On Wed, Jun 25, 2014 at 2:44 PM, Brian Hanifin [email protected]
|
|
I rm'd my bower_components first, then ran npm install. On Wed, Jun 25, 2014 at 2:47 PM, Benjamin West [email protected] wrote:
|
|
I just switch local branches to and tried npm install. That solved it. |
|
One last thing I need to look at here... I need to make sure the /pebble JSON isn't getting cached. |
|
I was right, I need to remove the caching headers on /pebble |
|
OK, I moved the static server and caching header definitions to the bottom, so the dynamic URLs higher up in the code are not cached. This is all that is left in the /pebble response header. Since no caching is mentioned, I assume we are golden. |
|
I think the mp3 cache should not result in There is another trick to try as well: using a "data-uri" uri blob to hold the mp3 binary, and then just play that again and again. It should result in keeping one instance of the mp3 in browser memory rather than attempting to request over the network. Something like this, but for mp3 http://stackoverflow.com/questions/4998908/convert-data-uri-to-file-then-append-to-formdata. |
|
Interesting, so Firefox’s Live HTTP Headers extension also reports a 206 (see the 1st and 2nd load headers in this Gist). https://gist.github.com/brianhanifin/74465ee3fceedec9f6cd So it must be Express returning the 206, and not Chrome. I have some more research to do. Brian On June 25, 2014 at 3:32:34 PM, Ben West ([email protected]) wrote: I think the mp3 cache should not result in 206, but should result in 304 instead. The 206 is Chrome being smart and cancelling the request, I think. If there were a 304 response for the second alarm, it should result in no traffic. There is another trick to try as well: using a "data-uri" uri blob to hold the mp3 binary, and then just play that again and again. It should result in keeping one instance of the mp3 in browser memory rather than attempting to request over the network. Something like this, but for mp3 http://stackoverflow.com/questions/4998908/convert-data-uri-to-file-then-append-to-formdata. — |
|
We are now getting 304 status codes! :) The expires header was improperly formatted. I added the “dateformat” npm library so I could correct the format. I discovered a great site called redbot.org and it allowed me to set a If-None-Match header so I could test this. Woohoo! HTTP/1.1 304 Not Modified |
|
Wow, very nice work!!! ❤️ this! That service is pretty nifty, what a find. |
Tested by deleting everything, running npm install from scratch.
This helps ensure that only the files in the static subdirectory can be served.
Should eliminate serving config files via http.