Problems with RJS w/ Lighttpd & Ubuntu

I have my code working on my local machine no problem, but when I upload
to the server the RJS effects I have aren’t working. The server is
running Ubuntu Dapper w/ lighttpd while on my local machine I’m using
webrick.

For kicks I shut down lightty and booted my app on the server with
webrick and it works fine. So it’s definitely a lightty issue.

Anyone else seen it and/or know how to resolve?

Just a guess, but it sounds like lighty is munging your javascript
files somehow. Can you further illuminate your server’s setup? Does
the following return a gob of javascript code?

http://yourserver.com/javascripts/effects.js

Eden Li wrote:

Just a guess, but it sounds like lighty is munging your javascript
files somehow. Can you further illuminate your server’s setup? Does
the following return a gob of javascript code?

http://yourserver.com/javascripts/effects.js

Yeah I just see code when I try that. I shut down lightty and used
webrick as a test and it works. So it’s definitely an issue with
lighttpd. :frowning: I’m on version 1.4.11 using Ubuntu Dapper. Looks like
1.4.13 is out but not yet in the repos.

I suppose I will have to try manually installing it to see if that
solves my issue.

Eden Li wrote:

Can you further illuminate your server’s setup?

Here is my lighttpd.conf:

server.modules = (
“mod_rewrite”,
“mod_redirect”,
“mod_access”,
“mod_fastcgi”,
“mod_compress”,
“mod_accesslog”)

server.document-root = “/var/www”
server.bind = “0.0.0.0”
server.port = 80
server.pid-file = “/tmp/main_lighttpd.pid”
server.tag = “lighttpd”
server.errorlog = “/var/log/lighttpd.error.log”
server.indexfiles =
(“index.php”,“index.html”,“index.htm”,“default.htm”)

$HTTP[“host”] =~ “(^|.)beta.myapp.net” {
url.access-deny = ( “~”, “.php” )
server.document-root = “/var/www/myapp/public/”
server.error-handler-404 = “/dispatch.fcgi”
server.indexfiles = (“dispatch.fcgi”)
accesslog.filename = “/var/log/myapp.access.log”
fastcgi.server = (“.fcgi” =>
(“localhost” =>
(“socket” => “/tmp/myapp.socket”,
“min-procs” => 2,
“max-procs” => 2,
“bin-path” => “/var/www/myapp/public/dispatch.fcgi”,
“bin-environment” => (“RAILS_ENV” => “development”)
)))
}

mimetype.assign = (
“.pdf” => “application/pdf”,
“.sig” => “application/pgp-signature”,
“.spl” => “application/futuresplash”,
“.class” => “application/octet-stream”,
“.ps” => “application/postscript”,
“.torrent” => “application/x-bittorrent”,
“.dvi” => “application/x-dvi”,
“.gz” => “application/x-gzip”,
“.pac” => “application/x-ns-proxy-autoconfig”,
“.swf” => “application/x-shockwave-flash”,
“.tar.gz” => “application/x-tgz”,
“.tgz” => “application/x-tgz”,
“.tar” => “application/x-tar”,
“.zip” => “application/zip”,
“.mp3” => “audio/mpeg”,
“.m3u” => “audio/x-mpegurl”,
“.wma” => “audio/x-ms-wma”,
“.wax” => “audio/x-ms-wax”,
“.ogg” => “audio/x-wav”,
“.wav” => “audio/x-wav”,
“.gif” => “image/gif”,
“.jpg” => “image/jpeg”,
“.jpeg” => “image/jpeg”,
“.png” => “image/png”,
“.xbm” => “image/x-xbitmap”,
“.xpm” => “image/x-xpixmap”,
“.xwd” => “image/x-xwindowdump”,
“.css” => “text/css”,
“.html” => “text/html”,
“.htm” => “text/html”,
“.js” => “text/javascript”,
“.asc” => “text/plain”,
“.c” => “text/plain”,
“.conf” => “text/plain”,
“.text” => “text/plain”,
“.txt” => “text/plain”,
“.dtd” => “text/xml”,
“.xml” => “text/xml”,
“.mpeg” => “video/mpeg”,
“.mpg” => “video/mpeg”,
“.mov” => “video/quicktime”,
“.qt” => “video/quicktime”,
“.avi” => “video/x-msvideo”,
“.asf” => “video/x-ms-asf”,
“.asx” => “video/x-ms-asf”,
“.wmv” => “video/x-ms-wmv”,
“.bz2” => “application/x-bzip”,
“.tbz” => “application/x-bzip-compressed-tar”,
“.tar.bz2” => “application/x-bzip-compressed-tar”
)

Ok, I updated to lighttpd 1.4.13 (latest) but am still having the same
problem. I am stumped.

Anyone have any ideas? Here is the .rjs in question:

page << “var a=0;”
if @mapsnew
for mapsnew in @mapsnew
page << “var e=new GLatLng(#{params[:evt_latitude]},
#{params[:evt_longitude]}).distanceFrom(new GLatLng( #{mapsnew.latitude}
, #{mapsnew.longitude.to_f} ))/1000;”
page << “if(a==0){”
@evnt=Event.find(mapsnew.event_id)
page.replace_html ‘maplist’, content_tag(‘li’, “#{@evnt.event_head[0…25]}…” , :id =>
‘list_item’ )
page << “}else{”
page.insert_html :bottom, ‘maplist’, content_tag(‘li’, “#{@evnt.event_head[0…25]}…” , :id =>
‘list_item’ )
page << “}”
page << “a=a+1;”
end
else
page.replace_html ‘maplist’, content_tag(‘li’, “No events to
list!!!” , :id => ‘list_item’ )
end

Eden Li wrote:

Anyone else? Am I missing anything?

I finally solved this… firebug gave me some clues. Turns out my POST
requests were showing up like this:

Connection: close
Transfer-Encoding: chunked
38.909643Content-Type: text/javascript
Set-Cookie: _session_id=246ae40922c0fd45f1514aeb4bf790ae; path=/
Cache-Control: no-cache
Date: Tue, 10 Oct 2006 19:41:35 GMT
Server: lighttpd

That 38.909643 figure was obscuring the Content-Type so it wasn’t
getting picked up. I had a print statement which was putting out that
number and as soon as I erased it from my code everything started
working again.

I have no idea why lightty would pick up a print statement as part of
the post though. Seems like that has to be a bug.

Anyway, thanks for taking the time to look through this with me!

Really strange. Your config looks fine (although I speak from only
having run lighty+fcgi a few times, I’ve switched to mongrel+pen+lighty
since).

A few more things to check:

  • Make sure that the RJS action is even being hit by looking in the
    development.log (you’ve told it to go into development mode on purpose,
    right?). Also check this log to see if any exceptions are being
    thrown.
  • Open up the rendered page and double check the javascript to make
    sure the action is being referenced properly.
  • Try hitting the RJS action directly with your browser to see what you
    get back (provided you’ve not hidden it behind a request.xhr? check)

Anyone else? Am I missing anything?

Ooh, ouch.

Looks like others have run into this as well:
http://source.mihelac.org/articles/2006/06/05/do-not-use-puts-in-rails

I like to use “logger” and “raise object.to_yaml” during debugging.
The former will harmlessly log into your log/#{RAILS_ENV}.log file and
the latter is so noticeable (and easy to grep for) it’ll be hard to
miss it during a deploy.