Forum: Radiant CMS Styles 'n Scripts Extension Erros

9389724dc0ba69ce08a6c2786d997931?d=identicon&s=25 Arik Jones (imakethings)
on 2008-05-28 23:23
=========
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?
5d7970d97d3cd33fcd85696b87a4611e?d=identicon&s=25 Chris Parrish (cparrish)
on 2008-05-28 23:44
(Received via mailing list)
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
9389724dc0ba69ce08a6c2786d997931?d=identicon&s=25 Arik Jones (imakethings)
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
26ed4a46e321f6f0f77a55b228a47145?d=identicon&s=25 Jay Levitt (Guest)
on 2008-06-02 22:48
(Received via mailing list)
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
5d7970d97d3cd33fcd85696b87a4611e?d=identicon&s=25 Chris Parrish (cparrish)
on 2008-06-03 08:00
(Received via mailing list)
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
9389724dc0ba69ce08a6c2786d997931?d=identicon&s=25 Arik Jones (imakethings)
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
9389724dc0ba69ce08a6c2786d997931?d=identicon&s=25 Arik Jones (imakethings)
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
26ed4a46e321f6f0f77a55b228a47145?d=identicon&s=25 Jay Levitt (Guest)
on 2008-06-03 18:11
(Received via mailing list)
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
5d7970d97d3cd33fcd85696b87a4611e?d=identicon&s=25 Chris Parrish (cparrish)
on 2008-06-03 19:38
(Received via mailing list)
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
26ed4a46e321f6f0f77a55b228a47145?d=identicon&s=25 Jay Levitt (Guest)
on 2008-06-04 00:05
(Received via mailing list)
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
D29c53311c32eb408aaba2e5ae55d161?d=identicon&s=25 Christopher Dwan (Guest)
on 2009-04-10 02:27
(Received via mailing list)
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
09477c358c5897d44121a248326e16d7?d=identicon&s=25 Jim Gay (Guest)
on 2009-04-10 02:56
(Received via mailing list)
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.
8802b1fa1b53e2197beea9454244f847?d=identicon&s=25 Sean Cribbs (seancribbs)
on 2009-04-10 03:58
(Received via mailing list)
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
This topic is locked and can not be replied to.