========= 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?
on 2008-05-28 23:23
on 2008-05-28 23:44
Arik Jones 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
on 2008-05-29 00:15
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 Parrish wrote: > Arik Jones 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
on 2008-06-02 22:48
Chris Parrish wrote: > Arik Jones 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:in `headers=' > /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
on 2008-06-03 08:00
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/rad...
-Chris
on 2008-06-03 15:24
I didn't get it to work... I installed the newest version from latest. No go. Chris Parrish 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/rad... > > > -Chris
on 2008-06-03 15:27
Ahhhh... geez. Had to clean out the cache. Now it works like a charm! Thanks Chris! You're awesome. Arik Jones wrote: > I didn't get it to work... I installed the newest version from latest. > No go. > > Chris Parrish 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/rad... >> >> >> -Chris
on 2008-06-03 18:11
Chris Parrish wrote: > Let me know how this works. > > This new version is available at: > https://secure.svnrepository.com/s_swanki/open/rad... 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
on 2008-06-03 19:38
Jay Levitt 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 http://www.distantmusic.com/css/default 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
on 2008-06-04 00:05
Chris Parrish wrote: > Jay Levitt 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
on 2009-04-10 02:27
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
on 2009-04-10 02:56
On Apr 9, 2009, at 8:25 PM, Christopher Dwan 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.
on 2009-04-10 03:58
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
Enable email notification
Enable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.