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

Discuss Serving Static Content From Another Server #345

Closed
Zren opened this issue Sep 7, 2014 · 7 comments · Fixed by #352
Closed

Discuss Serving Static Content From Another Server #345

Zren opened this issue Sep 7, 2014 · 7 comments · Fixed by #352
Labels
needs discussion Blah, blah, blah, wahh, wahh, wahh, etc. team biz This is similar to a meta discussion.
Milestone

Comments

@Zren
Copy link
Contributor

Zren commented Sep 7, 2014

503s are prominent enough that you'll get 2-4 every page load.
One 503 will break the entire page.
That cache is completely ignored if you get a 503.

Either have a seperate Apache server under a subdomain (eg: static.openuserjs.org) or use a public CDN.

Sorry Martii. Having the site be useful outweighs any security concerns of not hosting our own javascript.

We can host Ace locally (as it appears to not work on a CDN) but it's not on every page anyways.

@Martii Martii added needs discussion Blah, blah, blah, wahh, wahh, wahh, etc. needs testing Anyone can add this but it is primarily there for the Assignee indicating that Testers are wanted. labels Sep 7, 2014
@Martii
Copy link
Member

Martii commented Sep 7, 2014

This is still blocked with #343 with needs testing and now here. There's nothing to be sorry about. Don't work on this until fully documented with any presented 503s _(the toobusy-js package 503 main page does not apply here nor do times around scheduled redeployment)_ ... you need to do the same by posting maffs somewhere... screenshots won't be accepted...This will take some time to document as you've given it a whole half of a day to propagate caching to clients and no recent applicable proof.

@Martii Martii self-assigned this Sep 7, 2014
@Martii Martii added the team biz This is similar to a meta discussion. label Sep 7, 2014
@Martii Martii changed the title Serve Static Content From Another Server Discuss Serving Static Content From Another Server Sep 7, 2014
@Martii Martii added this to the #345 milestone Sep 7, 2014
@Martii
Copy link
Member

Martii commented Sep 7, 2014

Starting this off.... jQuery. There are a few available CDNs that can handle this that are official.

EDIT: Discussing out loud with a sample source tree:

  • ./dist
    • ./dist/jquery
      • ./dist/jquery/jquery-2.1.1.min.js
  • ./tests
  • ./dev
  • ./src
    • ./src/libs
    • ...

and so on and so forth.

  • Anything not yet discovered.

Some rules:

  1. Served external scripts and other used content must not require that sites JavaScript on the client to be enabled ever in order to be retrieved.
  2. Must be https for 100% of content served.
  3. Preferably tracked and visible history.
  4. Under our control not some vague CDN like cloudflare which gives equal if not more 503's various times during the day prior to caching.

@Martii
Copy link
Member

Martii commented Sep 7, 2014

The somewhere for maffs is now on our wiki in the maff subfolder. If you are unfamiliar with maffs please visit https://addons.mozilla.org/firefox/addon/mozilla-archive-format/ and please ensure that it is a single compressed zip with the .maff extension. It doesn't take a rocket scientist to save a page with this add-on. If you are using a different browser then you need to find one for that browser if available... if not then you have to do it in Moz... if no maffs are present then this issue could be closed with invalid... e.g. participation is optional but if you observe one save the page and save http://status.nodejitsu.com and post those in. This will track everything and don't worry about overwriting things there in that folder because the git visualization will handle that.

As you can see @Zren I'm way ahead of you and I've given this quite a bit of thought. :)

@jimaek
Copy link

jimaek commented Sep 7, 2014

Maybe jsDelivr could help?
We have a custom setup available

@Zren
Copy link
Contributor Author

Zren commented Sep 8, 2014

Served external scripts and other used content must not require that sites JavaScript on the client to be enabled ever in order to be retrieved.

What does that limit us to? CDNs that only serve their content on a subdomain?

@Martii
Copy link
Member

Martii commented Sep 8, 2014

What does that limit us to?

This part was difficult to word which is why it got appended to multiple times. Disable JavaScript and load the target url into the address bar in a new tab... if the resource doesn't show up properly (MIME type and all) due to a requirement of JavaScript being enabled then it's a no go.


Maybe jsDelivr could help?
We have a custom setup available

Will check it out. I'm definitely interested in proper load balancing when an outage occurs. Thanks.

@Martii
Copy link
Member

Martii commented Sep 29, 2014

Heads up... no one has posted any maffs or any other message regarding this issue. Possibly later today or tomorrow it will be closed.

Martii pushed a commit to Martii/OpenUserJS.org that referenced this issue Sep 30, 2014
* Use proper usage of `maxLag` for process bump.
* Add in simple referer check mentioned in OpenUserJS#343 to prevent SEO/abuse.
* Remove separator from `./routesStatic.js` and let `join` do it's op.

Closes OpenUserJS#345

**NOTE**: Server cloud services may already handle load balancing but keeping this in for the time being... if it crops up again, bump to a maximum of 175ms. toobusy-js does use timers that are never stopped even at the equivalient of `document-idle` event state. If this package proves long term to be an issue remove it completely... however during testing period it **PASSED**.
@Martii Martii removed their assignment Oct 1, 2014
@Martii Martii removed the needs testing Anyone can add this but it is primarily there for the Assignee indicating that Testers are wanted. label Oct 1, 2014
Martii pushed a commit to Martii/OpenUserJS.org that referenced this issue Apr 6, 2016
* Reinstate *toobusy-js*... at least one of their timers has been fixed on shutdown. See OpenUserJS#354, OpenUserJS#353, OpenUserJS#352 and base issue of OpenUserJS#345 ... loosely related to OpenUserJS#249 and attempt to address OpenUserJS#944 with a work-around... VPS should be faster than our old one so perhaps the timers don't make as much of a difference. Start with our old default lag value... this may introduce too many 503's again but hopefully not
* Retested delete op
* Bug fixes, tests, and docs updates... please read their CHANGELOGS
* Shutdown the server on SIGINT
* Modify db closure to not have dependents
@Martii Martii mentioned this issue Apr 6, 2016
@OpenUserJS OpenUserJS locked as resolved and limited conversation to collaborators Apr 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
needs discussion Blah, blah, blah, wahh, wahh, wahh, etc. team biz This is similar to a meta discussion.
Development

Successfully merging a pull request may close this issue.

3 participants