Skip to content
This repository was archived by the owner on Mar 22, 2021. It is now read-only.

Conversation

@bewest
Copy link

@bewest bewest commented Jun 25, 2014

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.

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.
@bewest
Copy link
Author

bewest commented Jun 25, 2014

Would you mind testing this as well. Everything looks good here, but I gave it a very very quick review.

brianhanifin added a commit that referenced this pull request Jun 25, 2014
move static files into /static
@brianhanifin brianhanifin merged commit 4c10967 into brianhanifin:express-cache Jun 25, 2014
@brianhanifin
Copy link
Owner

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.

@bewest
Copy link
Author

bewest commented Jun 25, 2014

Hmm did you run npm install?

On Wed, Jun 25, 2014 at 2:44 PM, Brian Hanifin [email protected]
wrote:

The bower_components folder did not get moved into /static. I manually
moved it and it works, but something is off.


Reply to this email directly or view it on GitHub
#3 (comment)
.

@bewest
Copy link
Author

bewest commented Jun 25, 2014

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:

Hmm did you run npm install?

On Wed, Jun 25, 2014 at 2:44 PM, Brian Hanifin [email protected]
wrote:

The bower_components folder did not get moved into /static. I manually
moved it and it works, but something is off.


Reply to this email directly or view it on GitHub
#3 (comment)
.

@brianhanifin
Copy link
Owner

I just switch local branches to and tried npm install. That solved it.

@brianhanifin
Copy link
Owner

One last thing I need to look at here... I need to make sure the /pebble JSON isn't getting cached.

@brianhanifin
Copy link
Owner

I was right, I need to remove the caching headers on /pebble

HTTP/1.1 200 OK
Arr-Disable-Session-Affinity: True
Cache-Control: public, max-age=2592000
Connection: keep-alive
content-type: application/json
Date: Wed, 25 Jun 2014 21:51:51 GMT
Expires: Fri Jul 25 2014 14:51:23 GMT-0700 (PDT)
Transfer-Encoding: chunked
X-Powered-By: Express

@brianhanifin
Copy link
Owner

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.

HTTP/1.1 200 OK
content-type: application/json
Date: Wed, 25 Jun 2014 22:01:29 GMT
X-Powered-By: Express

@bewest
Copy link
Author

bewest commented Jun 25, 2014

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.

@brianhanifin
Copy link
Owner

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.


Reply to this email directly or view it on GitHub.

@brianhanifin
Copy link
Owner

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!

https://redbot.org/?uri=http%3A%2F%2Fcgmtest.azurewebsites.net&req_hdr=If-None-Match%3AW%2F%22GrbitMGKXP9o563b%2BTbsOw%3D%3D%22

HTTP/1.1 304 Not Modified
    Cache-Control: public, max-age=2592000
    Expires: Sat, 26 Jul 2014 22:41:40 GMT
    Last-Modified: Wed, 25 Jun 2014 22:45:02 GMT
    Accept-Ranges: bytes
    ETag: W/"GrbitMGKXP9o563b+TbsOw=="
    Server: Microsoft-IIS/8.0
    X-Powered-By: Express
    X-Powered-By: ASP.NET
    Date: Thu, 26 Jun 2014 22:42:50 GMT

@bewest
Copy link
Author

bewest commented Jun 26, 2014

Wow, very nice work!!! ❤️ this! That service is pretty nifty, what a find.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants