search

mdzidic / ovz-web-panel

Automatically exported from code.google.com/p/ovz-web-panel
Other
0 stars 0 forks source link

Internal Server Error - private method 'gsub' #366

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I experiment an extrange bug when I try to access to OVZ with Mozilla Firefox 
(my version is 5.0.1)

Seems when the browser try to get the JS sources an extrange server error 
returns. This is the HTML ouput returned:

GET: /ext/adapter/ext/ext-base.js?1285488870
CONTENT SERVER RESPONSE:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
  <HEAD><TITLE>Internal Server Error</TITLE></HEAD>
  <BODY>
    <H1>Internal Server Error</H1>
    private method `gsub!' called for #&lt;Class:0x2ae166b75530&gt;
    <HR>
    <ADDRESS>

     WEBrick/1.3.1 (Ruby/1.8.5/2006-08-25) OpenSSL/0.9.8e-rhel5 at
     vps.fiwall.net:443
    </ADDRESS>
  </BODY>
</HTML>

The JS console return this error:
Ext is not defined.

I think this error ocurred because the concatenated GET string "?1285488870" 
have an encoding error in Mozilla Firefox and the server (WEBRick) cannot 
handle it correctly, but, if I remove the "?1285488870" string the server 
respond correctly.
This error acurre for JS sources and CSS.

Surely this bug doesn't dipend on OVZ, but, if there is a bug of WEBRick or 
other package, it should be upgraded.

Original issue reported on code.google.com by th2...@gmail.com on 29 Oct 2011 at 2:35

GoogleCodeExporter commented 9 years ago 
I also have tested it on Mozilla Firefox 7.0.1 and the same bug acurre.

Original comment by th2...@gmail.com on 29 Oct 2011 at 2:40

GoogleCodeExporter commented 9 years ago 
I have looked at this issue using FireBug and discovered that the cause is that 
the code in layouts/_header.html.erb (as follows):

    <%= stylesheet_link_tag @extjs_base_url + '/resources/css/ext-all.css' %>
    <%= stylesheet_link_tag 'application' %>
    <%= javascript_include_tag @extjs_base_url + '/adapter/ext/ext-base.js' %>
    <%= javascript_include_tag @extjs_base_url + '/ext-all.js' %>
    <%= javascript_include_tag 'application' %>
    <%= javascript_include_tag '/ext/locale/ext-lang-' + I18n.locale.to_s + '.js' %>

Is rendered in the HTML as:

    <link href="/ext/resources/css/ext-all.css?1285488870" media="screen" rel="stylesheet" type="text/css" />
    <link href="/stylesheets/application.css?1302428434" media="screen" rel="stylesheet" type="text/css" />
    <script src="/ext/adapter/ext/ext-base.js?1285488870" type="text/javascript"></script>
    <script src="/ext/ext-all.js?1285488870" type="text/javascript"></script>
    <script src="/javascripts/application.js?1299943460" type="text/javascript"></script>
    <script src="/ext/locale/ext-lang-en.js?1285488870" type="text/javascript"></script>

If you try to access: /ext/resources/css/ext-all.css?1285488870 directly you 
get the error:

     Internal Server Error
     private method `gsub!' called for #<Class:0xb7042a74> 
     WEBrick/1.3.1 (Ruby/1.8.5/2006-08-25)

The reason for this is that WEBrick is expecting aURL of the form 
{URL}?{parameter}={value}
rather than {URL}?{value}

If you try to access /ext/resources/css/ext-all.css?number=1285488870 then you 
get the text returned as you would expect. Alternatively adding = to the end of 
the number works as well. 

There must be some difference n the way these URLs are being encoded by Firefox 
compared with, say Chrome.

I have not checked out the stylesheet_link_tag or javascript_include_tag code, 
but I assume if this were modified to include an = then this would fix it.

On the other hand, I would not expect to see this kind of cache busting URL 
parameter in use on production systems, and the preferred solution for a 
non-development installation would be to omit the ?1285488870 part entirely.

With best regards, Pehr

Original comment by pehr.tor...@gmail.com on 29 Nov 2011 at 9:58

GoogleCodeExporter commented 9 years ago 
The cause of this is as follows:

6.4 AssetTag Timestamp Caching
You’re likely familiar with Rails’ practice of adding timestamps to static 
asset paths as a “cache buster.” This helps ensure that stale copies of 
things like images and stylesheets don’t get served out of the user’s 
browser cache when you change them on the server. You can now modify this 
behavior with the cache_asset_timestamps configuration option for Action View. 
If you enable the cache, then Rails will calculate the timestamp once when it 
first serves an asset, and save that value. This means fewer (expensive) file 
system calls to serve static assets – but it also means that you can’t 
modify any of the assets while the server is running and expect the changes to 
get picked up by clients.

This can be disabled with:      ENV['RAILS_ASSET_ID'] = ""
for example in environment.rb

Original comment by pehr.tor...@gmail.com on 2 Dec 2011 at 8:38

GoogleCodeExporter commented 9 years ago 
I can confirm that setting ENV['RAILS_ASSET_ID'] = ""
in 
/opt/ovz-web-panel/config/environment.rb

solves this problem with FireFox 8.0.1

You will have to restart OVZ Web Panel to get this to work: 
/opt/ovz-web-panel/script/owp restart

If you upgrade OVZ Web Panel, it may be necessary to clear your browser cache 
to 
ensure you get the latest code, since setting ENV['RAILS_ASSET_ID'] to "" turns 
off
the cache busting effect of the links. However, since you only have to do this 
once
for any given upgrade, this should not be a problem.

I suggest that OVZ Web Panel is shipped with ENV['RAILS_ASSET_ID'] = "" and a 
note to 
this effect.

With best regards, Pehr

Original comment by pehr.tor...@gmail.com on 4 Dec 2011 at 5:43

GoogleCodeExporter commented 9 years ago 
Solved! Thanks a lot!

Original comment by th2...@gmail.com on 4 Dec 2011 at 5:47

GoogleCodeExporter commented 9 years ago

Original comment by sibprogrammer on 5 Dec 2011 at 4:23

GoogleCodeExporter commented 9 years ago 
Guys, see no reason to workaround this problem for Ruby 1.8.5! Really it's very 
old version of Ruby.

Original comment by sibprogrammer on 20 Feb 2012 at 2:55