librelist archives

« back to archive

Static assets in /public—is there a more nesta-blessed way?

Static assets in /public—is there a more nesta-blessed way?

From:
Chad Ostrowski
Date:
2012-06-10 @ 17:49
I'm working on making some slides. Here's my "it works!" example 
(http://hellointerweb.com/week-1). You can see in my source code 
(https://github.com/chadoh/hellointerweb) that I just dropped all the 
reveal.js (https://github.com/hakimel/reveal.js) stuff into the /public 
folder.

Visiting /index.html (http://hellointerweb.com/index.html) (the reveal.js 
sample) always works and loads all of the other assets just fine. "Always 
works" means in production (which I'm linking you to) and in dev on my 
machine.

HOWEVER. The "It works!" page (/week-1) works in prod but often fails to 
find assets in development. The prod link works every time. But 90% of the
time when I bring up the page in dev, at least one of the javascripts or 
stylesheets is missing.

Now, the /week-1 page is served by nesta from /content/pages/ (with a 
layout mimicking /index.html in /views). But all of the assets it's 
linking to are in /public. Is that the issue? Is there a better place to 
put these sort of static assets? 

Re: [nesta] Static assets in /public—is there a more nesta-blessed way?

From:
Graham Ashton
Date:
2012-06-11 @ 12:20
On 10 Jun 2012, at 18:49, Chad Ostrowski wrote:

> But all of the assets it's linking to are in /public. Is that the issue?
Is there a better place to put these sort of static assets?

That's the best place to put them; they bypass Sinatra and just get served
off disk by whichever web server you're using.

I'd try and get some logging enabled in development, and try an 
alternative development web server too. Logs should tell you whether or 
not the page is even trying to request them.

First off, I'd try starting the app with thin rather than shotgun and 
seeing whether or not all your assets get loaded.

Also investigate the network traffic with a tool like Firebug, or the 
Webkit dev tools in Google Chrome or Safari.

Re: [nesta] Static assets in /public—is there a more nesta-blessed way?

From:
Chad Ostrowski
Date:
2012-06-16 @ 14:39
You know, I have no idea how to turn on logging. I've been using Thin; it 
doesn't print anything to STDOUT, and if there's a log file I'm not sure 
where to find it. I tried adding my own app.rb and following the 
instructions on http://www.sinatrarb.com/intro.html#Logging, to no avail. 
When I print out `env['rack.logger']` in my code, it says 
"#<Rack::NullLogger:0x94921f0>". That seems bad, and I'm not sure what to 
do about it. (I'm pathetically unused to setting up my own logging!)

I have been looking at the network traffic in the webkit inspector in 
Chrome, and when the assets are missing, it says that finding files like 
"/lib/classList.js" failed. Permanent pending (that is, I'm not getting 
404s, the request just never comes back).

My hunch is that, since the request is passed to my Sinatra app for 
processing (because it's to a page in /content/pages), Sinatra/Nesta for 
some reason attempts to also serve the assets in /public, even though it 
should leave it up to Thin.  


El lunes, junio 11, 2012 a las 8:20 AM, Graham Ashton escribió:

> On 10 Jun 2012, at 18:49, Chad Ostrowski wrote:
>  
> > But all of the assets it's linking to are in /public. Is that the 
issue? Is there a better place to put these sort of static assets?
>  
> That's the best place to put them; they bypass Sinatra and just get 
served off disk by whichever web server you're using.
>  
> I'd try and get some logging enabled in development, and try an 
alternative development web server too. Logs should tell you whether or 
not the page is even trying to request them.
>  
> First off, I'd try starting the app with thin rather than shotgun and 
seeing whether or not all your assets get loaded.
>  
> Also investigate the network traffic with a tool like Firebug, or the 
Webkit dev tools in Google Chrome or Safari.  

Re: [nesta] Static assets in /public—is there a more nesta-blessed way?

From:
Chad Ostrowski
Date:
2012-06-16 @ 15:00
Actually, when Thin has an error (and I get an actual stack trace page), 
Thin does print the error to STDOUT. So that's not happening when these 
assets go missing.

El sábado, junio 16, 2012 a las 10:39 AM, Chad Ostrowski escribió:

> You know, I have no idea how to turn on logging. I've been using Thin; 
it doesn't print anything to STDOUT, and if there's a log file I'm not 
sure where to find it. I tried adding my own app.rb and following the 
instructions on http://www.sinatrarb.com/intro.html#Logging, to no avail. 
When I print out `env['rack.logger']` in my code, it says 
"#<Rack::NullLogger:0x94921f0>". That seems bad, and I'm not sure what to 
do about it. (I'm pathetically unused to setting up my own logging!)
>  
> I have been looking at the network traffic in the webkit inspector in 
Chrome, and when the assets are missing, it says that finding files like 
"/lib/classList.js" failed. Permanent pending (that is, I'm not getting 
404s, the request just never comes back).
>  
> My hunch is that, since the request is passed to my Sinatra app for 
processing (because it's to a page in /content/pages), Sinatra/Nesta for 
some reason attempts to also serve the assets in /public, even though it 
should leave it up to Thin.  
>  
> El lunes, junio 11, 2012 a las 8:20 AM, Graham Ashton escribió:
>  
> > On 10 Jun 2012, at 18:49, Chad Ostrowski wrote:
> >  
> > > But all of the assets it's linking to are in /public. Is that the 
issue? Is there a better place to put these sort of static assets?
> >  
> > That's the best place to put them; they bypass Sinatra and just get 
served off disk by whichever web server you're using.
> >  
> > I'd try and get some logging enabled in development, and try an 
alternative development web server too. Logs should tell you whether or 
not the page is even trying to request them.
> >  
> > First off, I'd try starting the app with thin rather than shotgun and 
seeing whether or not all your assets get loaded.
> >  
> > Also investigate the network traffic with a tool like Firebug, or the 
Webkit dev tools in Google Chrome or Safari.  
>  

Re: [nesta] Static assets in /public—is there a more nesta-blessed way?

From:
Chad Ostrowski
Date:
2012-06-16 @ 15:16
Ah! I got my logs going to STDOUT by adding a proper app.rb (I had been 
screwing that up) and simply adding in `use Rack::CommonLogger`.

Here's what a request that fails to get all of the assets looks like:

    10.0.2.2 - - [16/Jun/2012 08:10:47] "GET /css/reset.css HTTP/1.1" 304 - 0.0086
    10.0.2.2 - - [16/Jun/2012 08:10:48] "GET /lib/zenburn.css HTTP/1.1" 
304 - 0.001910.0.2.2 - - [16/Jun/2012 08:10:48] "GET /lib/classList.js 
HTTP/1.1" 200 1582 0.0047
    10.0.2.2 - - [16/Jun/2012 08:10:48] "GET /js/reveal.js HTTP/1.1" 304 -
0.005910.0.2.2 - - [16/Jun/2012 08:10:48] "GET /css/print.css HTTP/1.1" 
304 - 0.0026


And here's what a successful request looks like:

    10.0.2.2 - - [16/Jun/2012 08:10:53] "GET /favicon.ico HTTP/1.1" 404 
2561 0.2632
    10.0.2.2 - - [16/Jun/2012 08:10:53] "GET /lib/zenburn.css HTTP/1.1" 
304 - 0.002310.0.2.2 - - [16/Jun/2012 08:10:53] "GET /css/reset.css 
HTTP/1.1" 304 - 0.0023
    10.0.2.2 - - [16/Jun/2012 08:10:53] "GET /css/main.css HTTP/1.1" 200 
24723 0.005910.0.2.2 - - [16/Jun/2012 08:10:53] "GET /lib/highlight.js 
HTTP/1.1" 200 23782 0.0416
    10.0.2.2 - - [16/Jun/2012 08:10:53] "GET /js/reveal.js HTTP/1.1" 304 -
0.002810.0.2.2 - - [16/Jun/2012 08:10:53] "GET 
/assets/fonts/leaguegothic/league_gothic-webfont.ttf HTTP/1.1" 304 - 
0.0028
    10.0.2.2 - - [16/Jun/2012 08:10:53] "GET /css/print.css HTTP/1.1" 304 - 0.0020
    10.0.2.2 - - [16/Jun/2012 08:11:16] "GET /favicon.ico HTTP/1.1" 404 
2561 0.1585

Note that this is hit-or-miss. The only thing I did to get the two 
different responses above was refresh the page. Sometimes the assets are 
found, sometimes they aren't.  


El sábado, junio 16, 2012 a las 11:00 AM, Chad Ostrowski escribió:

> Actually, when Thin has an error (and I get an actual stack trace page),
Thin does print the error to STDOUT. So that's not happening when these 
assets go missing.
>  
> El sábado, junio 16, 2012 a las 10:39 AM, Chad Ostrowski escribió:
>  
> > You know, I have no idea how to turn on logging. I've been using Thin;
it doesn't print anything to STDOUT, and if there's a log file I'm not 
sure where to find it. I tried adding my own app.rb and following the 
instructions on http://www.sinatrarb.com/intro.html#Logging, to no avail. 
When I print out `env['rack.logger']` in my code, it says 
"#<Rack::NullLogger:0x94921f0>". That seems bad, and I'm not sure what to 
do about it. (I'm pathetically unused to setting up my own logging!)
> >  
> > I have been looking at the network traffic in the webkit inspector in 
Chrome, and when the assets are missing, it says that finding files like 
"/lib/classList.js" failed. Permanent pending (that is, I'm not getting 
404s, the request just never comes back).
> >  
> > My hunch is that, since the request is passed to my Sinatra app for 
processing (because it's to a page in /content/pages), Sinatra/Nesta for 
some reason attempts to also serve the assets in /public, even though it 
should leave it up to Thin.  
> >  
> > El lunes, junio 11, 2012 a las 8:20 AM, Graham Ashton escribió:
> >  
> > > On 10 Jun 2012, at 18:49, Chad Ostrowski wrote:
> > >  
> > > > But all of the assets it's linking to are in /public. Is that the 
issue? Is there a better place to put these sort of static assets?
> > >  
> > > That's the best place to put them; they bypass Sinatra and just get 
served off disk by whichever web server you're using.
> > >  
> > > I'd try and get some logging enabled in development, and try an 
alternative development web server too. Logs should tell you whether or 
not the page is even trying to request them.
> > >  
> > > First off, I'd try starting the app with thin rather than shotgun 
and seeing whether or not all your assets get loaded.
> > >  
> > > Also investigate the network traffic with a tool like Firebug, or 
the Webkit dev tools in Google Chrome or Safari.  
> >  
>  

Re: [nesta] Static assets in /public—is there a more nesta-blessed way?

From:
Graham Ashton
Date:
2012-06-16 @ 21:11
On 16 Jun 2012, at 16:16, Chad Ostrowski wrote:

> Here's what a request that fails to get all of the assets looks like:
> 
>     10.0.2.2 - - [16/Jun/2012 08:10:47] "GET /css/reset.css HTTP/1.1" 
304 - 0.0086
>     10.0.2.2 - - [16/Jun/2012 08:10:48] "GET /lib/zenburn.css HTTP/1.1" 
304 - 0.001910.0.2.2 - - [16/Jun/2012 08:10:48] "GET /lib/classList.js 
HTTP/1.1" 200 1582 0.0047
>     10.0.2.2 - - [16/Jun/2012 08:10:48] "GET /js/reveal.js HTTP/1.1" 304
- 0.005910.0.2.2 - - [16/Jun/2012 08:10:48] "GET /css/print.css HTTP/1.1" 
304 - 0.0026
> 
> Note that this is hit-or-miss. The only thing I did to get the two 
different responses above was refresh the page. Sometimes the assets are 
found, sometimes they aren't.

I'm 90% confident that this is nothing to do with Nesta. What you're 
seeing there is logs for 5 successful requests, and 0 unsuccessful 
requests. The lines with the 304 HTTP code in them are "not modified" (the
server is telling the browser to use the version it has cached) and the 
200 for classList.js tells us that that file was served in full 
(successfully), probably because it had changed.

Errors to serve assets due to something going on in Sinatra/Nesta would 
still get logged, but they'd have different HTTP codes (e.g. 500).

Have you checked in your browser's developer tools whether the browser was
trying to request other files. You should be able to find out what HTTP 
response the browser thinks it got, if it did indeed attempt other 
connections. If in Chrome/Safari, try the Network tab in the Web 
Inspector, and then click on an asset. With the Headers tab selected in 
the right pane you should see HTTP request/response data.

I noticed in the second chunk of log messages that you included in your 
last email that classList.js was missing; perhaps it wasn't loaded in the 
'successful' page load, even though you felt it was successful as all 
other assets had been logged.

Either way, this is unlikely to be a Nesta problem; it's happening in a 
layer much closer to the metal. It could be a problem with your browser, 
your local networking, your Rack stack, or your development web server. 
It's unlikely to be the server because you've tried two now.

Have you added any Rack middleware over and above Rack::CommonLogger, and 
the stuff that is loaded by default with Nesta.

I can't offer any more assistance I'm afraid, short of booting up a copy 
of your app myself and seeing if I can reproduce it...

Graham