Styles 'n Scripts Extension Erros

Ruby Apps Radiant CMS
1

=========
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /css/tinypixel.css.

I’m getting a 502 proxy error when accessing any asset from the styles n
scripts extension. Checking the product logs, the process is being read
correctly and all is well on rails/radiant end. But for some reason
Apache doesn’t want to process the GET request. Any clues as to why?

2

Arik J. wrote:

=========
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /css/tinypixel.css.

I’m getting a 502 proxy error when accessing any asset from the styles n
scripts extension. Checking the product logs, the process is being read
correctly and all is well on rails/radiant end. But for some reason
Apache doesn’t want to process the GET request. Any clues as to why?

Hmm, I haven’t run into that one. Are you using any custom settings for
the extension? Is there anything else about your setup that isn’t a
standard Radiant install?

The Styles 'n Scripts extension has it’s own Response Cache but that
basically just inherits from Radiant’s ResponseCache and makes some
setting changes – nothing fancy.

And I’m not much of an Apache guru. Anyone out there in Radiant land
have any ideas what could trigger this?

-Chris

3

I found the problem. I was using the Thin Ruby HTTP Daemon. Switched
back to Mongrel and all is well! More or less a Thin issue. Sorry for
the bother.

Chris P. wrote:

Arik J. wrote:

=========
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /css/tinypixel.css.

I’m getting a 502 proxy error when accessing any asset from the styles n
scripts extension. Checking the product logs, the process is being read
correctly and all is well on rails/radiant end. But for some reason
Apache doesn’t want to process the GET request. Any clues as to why?

Hmm, I haven’t run into that one. Are you using any custom settings for
the extension? Is there anything else about your setup that isn’t a
standard Radiant install?

The Styles 'n Scripts extension has it’s own Response Cache but that
basically just inherits from Radiant’s ResponseCache and makes some
setting changes – nothing fancy.

And I’m not much of an Apache guru. Anyone out there in Radiant land
have any ideas what could trigger this?

-Chris

4

Chris P. wrote:

Arik J. wrote:

=========
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /css/tinypixel.css.

I’m getting a 502 proxy error when accessing any asset from the styles n
scripts extension. Checking the product logs, the process is being read
correctly and all is well on rails/radiant end. But for some reason
Apache doesn’t want to process the GET request. Any clues as to why?

I just ran into something like this, using Radiant 0.6.7, SnS 0.4, and -
like Arik had been - thin, proxied through Apache.

Turns out it’s not an Apache thing at all: it’s thin, complaining that
@response[‘Last-Modified’] isn’t a string. And it’s got a point!

undefined method each' for Mon Jun 02 15:59:23 UTC 2008:Time /usr/lib64/ruby/gems/1.8/gems/thin-0.8.1/lib/thin/response.rb:49:inheaders=’
/usr/lib64/ruby/gems/1.8/gems/thin-0.8.1/lib/thin/response.rb:48:in `each’

Suggestion for text_asset_site_controller:

# set the last modified date based on updated_at time for the asset
# we can do this as long as there is no dynamic content in the

assets

  •    response.headers['Last-Modified'] =

@text_asset.effectively_updated_at

  •    response.headers['Last-Modified'] =

@text_asset.effectively_updated_at.to_s
response.body = @text_asset.render

And I’m not much of an Apache guru. Anyone out there in Radiant land
have any ideas what could trigger this?

Jay

5

Thanks for the heads up, Jay! I’ve fixed the issue and just released
SnS v0.4.1

As it turns out, I actually needed to make the date conform to HTTP
header standards via:
response.headers[‘Last-Modified’] =
@text_asset.effectively_updated_at.httpdate

which, as you pointed out, is a string.

Let me know how this works.

This new version is available at:
https://secure.svnrepository.com/s_swanki/open/radiant/extensions/styles_n_scripts/tags/latest

-Chris

6

Ahhhh… geez. Had to clean out the cache. Now it works like a charm!
Thanks Chris! You’re awesome.

Arik J. wrote:

I didn’t get it to work… I installed the newest version from latest.
No go.

Chris P. wrote:

Thanks for the heads up, Jay! I’ve fixed the issue and just released
SnS v0.4.1

As it turns out, I actually needed to make the date conform to HTTP
header standards via:
response.headers[‘Last-Modified’] =
@text_asset.effectively_updated_at.httpdate

which, as you pointed out, is a string.

Let me know how this works.

This new version is available at:
https://secure.svnrepository.com/s_swanki/open/radiant/extensions/styles_n_scripts/tags/latest

-Chris

7

I didn’t get it to work… I installed the newest version from latest.
No go.

Chris P. wrote:

Thanks for the heads up, Jay! I’ve fixed the issue and just released
SnS v0.4.1

As it turns out, I actually needed to make the date conform to HTTP
header standards via:
response.headers[‘Last-Modified’] =
@text_asset.effectively_updated_at.httpdate

which, as you pointed out, is a string.

Let me know how this works.

This new version is available at:
https://secure.svnrepository.com/s_swanki/open/radiant/extensions/styles_n_scripts/tags/latest

-Chris

8

Chris P. wrote:

Let me know how this works.

This new version is available at:
https://secure.svnrepository.com/s_swanki/open/radiant/extensions/styles_n_scripts/tags/latest

Yep, that works too!

For what it’s worth, I am seeing a Flash of Unstyled Content (FOUC)
using
Firefox 3 nightly on a Mac. However, I see that with both your fix and
mine, and both directly through thin and through Apache, and it’s most
likely a client bug. Just thought I’d mention it in case someone else
sees
it too.

I didn’t see the FOUC with a “native” Radiant stylesheet, but I only had
it
set up for an hour in that config, so that doesn’t mean much. It
happens
about 1/3 of the time if I refresh the screen. (Site:
http://www.distantmusic.com)

Jay

9

Chris P. wrote:

Jay L. wrote:

Yep, that works too!

Good. Let me know if anything changes.

I’m not using FF3 at all so I can’t help you there but I am seeing some
interesting headers from your server…

So this makes me wonder whether or not v0.4.1 is working. Have you
cleared out the text_assets cache (see above)?

Yeah, but I had put the patched 0.4.0 back for a few minutes to see if
0.4.1
was causing the FOUC, so you must have hit my server right when I was
doing
that.

Looks OK now, right?

(BTW, the FOUC wasn’t from Sns; it was 90% due to a race condition in
the
ThumbStrips plugin, and 10% to
we-don’t-know-yet-but-certainly-client-side.)

Jay

10

This is driving me insane… I don’t understand it…

I’m getting extra text on the pages that are coming down from the
server. Sometimes the page doesn’t even load and all I get is the
text. Here it is:

PAGE URL = / Content-Type: text/html; charset=utf-8 Status: 304 Not
Modified Last-Modified: Fri, 10 Apr 2009 00:18:37 GMT ETag:
34b25f4f439eb3489e7f4fe3ff0869a191e2e75c X-Runtime: 0.25822 Content-
Length: 0

This doesn’t make any sense to me, where the heck is this coming from?

I have about 8 Radiant sites running on my server, all at different
versions. This is my first time with a 0.7.1 site. I just loaded the
site on the server to test it and fix any cross browser issues before
making it live.

I’m running LSWS (litespeed). Does it just not understand this extra
text that it’s being fed?

If you want to take a look yourself, here’s the site.
http://s1.radixhound.com

-C

11

Jay L. wrote:

Yep, that works too!

Good. Let me know if anything changes.

BTW, for others reading the list, you will need to clean out the old
cache to get the new date format to take (as Arik mentioned). This is
done automatically whenever you save any asset (javascript or
stylesheet).

http://www.distantmusic.com)

I’m not using FF3 at all so I can’t help you there but I am seeing some
interesting headers from your server…

First of all, for stylesheets. Here are the headers from three GETs
that I performed on DistantMusic.com is for sale | HugeDomains

Date: Tue, 03 Jun 2008 16:36:37 GMT
Server: thin 0.8.1 codename Rebel Porpoise
Last-Modified: Mon Jun 02 15:59:23 UTC 2008
Etag: “8b65d344a52c62c15ea473249b821741”
X-Runtime: 0.00222
Content-Type: text/css; charset=utf-8
Content-Length: 2486

200 OK

Date: Tue, 03 Jun 2008 16:57:29 GMT
Last-Modified: Mon Jun 02 15:59:23 UTC 2008

Date: Tue, 03 Jun 2008 16:58:08 GMT
Last-Modified: Mon Jun 02 15:59:23 UTC 2008

The 2nd and 3rd I obviously trimmed to show the important stuff. They
were from a refresh and hard refresh via FF 2.x

So, the parts I’m interested in:

  1. The Last-Modified date is not in the httpdate format (should be
    formatted just like the Date header and should state GMT – not
    UTC)
  2. Your server is not sending a Status: 304 Not Modified header (this
    might be related to the formatting issue above)

So this makes me wonder whether or not v0.4.1 is working. Have you
cleared out the text_assets cache (see above)?

Just FYI, here’s the same analysis for your homepage:

Date: Tue, 03 Jun 2008 16:56:28 GMT
Server: thin 0.8.1 codename Rebel Porpoise
Last-Modified: Tue, 03 Jun 2008 16:56:01 GMT
Etag: “21658f01a2ea4d561d1d0747824ee38f”
X-Runtime: 0.00482
Content-Type: text/html; charset=utf-8
Content-Length: 1176

200 OK

Date: Tue, 03 Jun 2008 17:10:01 GMT
Last-Modified: Tue, 03 Jun 2008 16:56:01 GMT

Date: Tue, 03 Jun 2008 17:11:25 GMT
Last-Modified: Tue, 03 Jun 2008 17:10:02 GMT

Two points here:

  1. I’m not seeing a 304 here either. So could this be a server
    config issue?
  2. I like seeing the render time difference that SnS affords

-Chris

12

On Apr 9, 2009, at 8:25 PM, Christopher D. wrote:

This doesn’t make any sense to me, where the heck is this coming from?

I have no idea why this is happening, but it looks like that is the
content from your cache.
Radiant caches the content and headers separately (_site_root.data and
_site_root.yml) and it looks like your server is sending back the
headers as text preceding the content.

13

My guess is that is happening somewhere inside LSWS. Do you have any
rewrite rules or filters applied? What concerns me is the PAGE URL
prefixing the standard HTTP headers.

I just tried your site and got the extra text the first time around,
then it was gone on refreshes.

Sean