Forum: Ruby on Rails Lighttpd file upload issue - sporadic choke?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
7aef4541a1355c993c66237b162d9681?d=identicon&s=25 Henry GP (henryp)
on 2005-11-18 03:09
This has been driving me crazy:  I have a file upload controller/view
that finally uploads a file with this code in the controller:

File.open("#{filepath}/#{filename}", "wb") do |f|
   f.write(@params[:document][:file].read)
end

This works great for files large and small in webbrick and in on an
Apache/FastCGI setup.  However, on my production box which is running
Lighttpd 1.4.7,  this functionality fails about 50% of the time for
files over 100 KB.  When I say 'fail', I mean that the file just never
appears in "#{filepath}/#{filename}".  The f.write command does not
throw an error and no errors appear in log/production.log,
log/fastcgi.crash.log or the lighttpd_error.log.   Very odd.

Is there some Lighttpd directive regarding upload file size I need to
include in my .conf file?  Some multipart chunk thing I need to know
about? How should I go about getting to the bottom of this?  (Please! I
dread wrestling with FastCGI/Apache again.)

Your help/suggestions are greatly appreciated.
54077fb03c95861af85880218cf7aef2?d=identicon&s=25 Gokhan Arli (sylow)
on 2005-12-14 23:53
I have the same issue, after 100K I have problem. Anybody has any idea?
I work with file_column + imagemagick

Any answer on this?

Henry Poydar wrote:
> This has been driving me crazy:  I have a file upload controller/view
> that finally uploads a file with this code in the controller:
>
> File.open("#{filepath}/#{filename}", "wb") do |f|
>    f.write(@params[:document][:file].read)
> end
>
> This works great for files large and small in webbrick and in on an
> Apache/FastCGI setup.  However, on my production box which is running
> Lighttpd 1.4.7,  this functionality fails about 50% of the time for
> files over 100 KB.  When I say 'fail', I mean that the file just never
> appears in "#{filepath}/#{filename}".  The f.write command does not
> throw an error and no errors appear in log/production.log,
> log/fastcgi.crash.log or the lighttpd_error.log.   Very odd.
>
> Is there some Lighttpd directive regarding upload file size I need to
> include in my .conf file?  Some multipart chunk thing I need to know
> about? How should I go about getting to the bottom of this?  (Please! I
> dread wrestling with FastCGI/Apache again.)
>
> Your help/suggestions are greatly appreciated.
7aef4541a1355c993c66237b162d9681?d=identicon&s=25 Henry GP (henryp)
on 2005-12-15 01:06
Gokhan Arli wrote:
> I have the same issue, after 100K I have problem. Anybody has any idea?
> I work with file_column + imagemagick
>
> Any answer on this?
>

For me the answer was to clear the cache I had stowed in
lib/image_upload_cache, make sure permissions were correct everywhere,
clearing all past ruby session files and restarting the server.  I'm not
sure where file_column caches things, but I would try and find out and
clear it out. HTH
648d60296e65a1278017c0b9f960ec3a?d=identicon&s=25 Oliver Barnes (Guest)
on 2005-12-15 11:20
(Received via mailing list)
Hi Henry,

I was hitting an upload limit of 4mb, which was solved on the latest
lighty release, 1.4.8. Also, if you're using Safari (I believe there
some issues with IE/PC as well), it might be worth adding this to your
lighttpd.conf:

$HTTP["useragent"] =~ "^(.*MSIE.*)|(.*AppleWebKit.*)$" {
    server.max-keep-alive-requests = 0
  }

Safari would choke on uploads above 64K, there was a thread about this
on textdrive i think

- Oliver

2005/12/14, Henry Poydar <hpoydar@gmail.com>:
648d60296e65a1278017c0b9f960ec3a?d=identicon&s=25 Oliver Barnes (Guest)
on 2005-12-15 11:20
(Received via mailing list)
(not sure whether the keep-alive-requests was solved on 1.4.8, btw...
might have)

2005/12/15, Oliver Barnes <ol1barn3s@gmail.com>:
This topic is locked and can not be replied to.