[#5737] returning strings from methods/instance_methods — TRANS <transfire@...>

I was just wondering why with #methods and #instance_methods, it was

11 messages 2005/09/08

[#5796] proposed attr writer patch — Daniel Berger <Daniel.Berger@...>

Hi all,

18 messages 2005/09/16

[#5798] Makefile error in OpenSLL extension (on Windows) — noreply@...

Bugs item #2472, was opened at 2005-09-16 18:56

11 messages 2005/09/17
[#5800] Re: [ ruby-Bugs-2472 ] Makefile error in OpenSLL extension (on Windows) — nobu.nokada@... 2005/09/17

Hi,

[#5851] Re: RubyGems in Ruby HEAD — Paul van Tilburg <paul@...>

Hi all,

34 messages 2005/09/21
[#5867] Re: RubyGems in Ruby HEAD — mathew <meta@...> 2005/09/21

Paul van Tilburg wrote:

[#5870] Re: RubyGems in Ruby HEAD — Marc Dequènes (Duck) <Duck@...> 2005/09/21

[#5920] Re: RubyGems in Ruby HEAD — mathew <meta@...> 2005/09/22

Marc Dequ竪nes (Duck) wrote:

[#5926] Re: RubyGems in Ruby HEAD — Pascal Terjan <pterjan@...> 2005/09/23

On 9/22/05, mathew <meta@pobox.com> wrote:

[#5931] Re: RubyGems in Ruby HEAD — Austin Ziegler <halostatue@...> 2005/09/23

On 9/23/05, Pascal Terjan <pterjan@gmail.com> wrote:

[#5898] Delegate and Forwardable Documentation — James Edward Gray II <james@...>

I've tried to send these files through a couple of times now with

17 messages 2005/09/22
[#5911] Re: Delegate and Forwardable Documentation — James Edward Gray II <james@...> 2005/09/22

On Sep 22, 2005, at 9:02 AM, James Edward Gray II wrote:

[#5924] Re: Delegate and Forwardable Documentation — James Edward Gray II <james@...> 2005/09/23

On Sep 22, 2005, at 11:53 AM, James Edward Gray II wrote:

[#5941] Re: Delegate and Forwardable Documentation — Yukihiro Matsumoto <matz@...> 2005/09/23

Hi,

[#5942] Re: Delegate and Forwardable Documentation — James Edward Gray II <james@...> 2005/09/23

On Sep 23, 2005, at 10:54 AM, Yukihiro Matsumoto wrote:

[#5947] Re: Delegate and Forwardable Documentation — Yukihiro Matsumoto <matz@...> 2005/09/23

Hi,

[#5921] Mutually dependent libs double loading. — TRANS <transfire@...>

I'm on Ruby 1.8.2.

14 messages 2005/09/23
[#5923] Re: Mutually dependent libs double loading. — Florian Gro<florgro@...> 2005/09/23

TRANS wrote:

[#5985] Finally an answer to my RubyGems question and some small suggestions — TRANS <transfire@...>

I appreciate those that attempted to offer me some info on this issue.

9 messages 2005/09/26

[#6001] Require Namepaces and RubyGems' effect on LoadPath problem — TRANS <transfire@...>

I've added namespaces to require. Works like this:

94 messages 2005/09/26
[#6002] Re: Require Namepaces and RubyGems' effect on LoadPath problem — Austin Ziegler <halostatue@...> 2005/09/26

On 9/26/05, TRANS <transfire@gmail.com> wrote:

[#6003] Re: Require Namepaces and RubyGems' effect on LoadPath problem — TRANS <transfire@...> 2005/09/26

On 9/26/05, Austin Ziegler <halostatue@gmail.com> wrote:

[#6005] Re: Require Namepaces and RubyGems' effect on LoadPath problem — Austin Ziegler <halostatue@...> 2005/09/26

On 9/26/05, TRANS <transfire@gmail.com> wrote:

[#6007] gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Sam Roberts <sroberts@...> 2005/09/26

Quoting halostatue@gmail.com, on Tue, Sep 27, 2005 at 06:02:07AM +0900:

[#6013] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Austin Ziegler <halostatue@...> 2005/09/27

On 9/26/05, Sam Roberts <sroberts@uniserve.com> wrote:

[#6014] Re: gems is a language change, not a pkging system — Sam Roberts <sroberts@...> 2005/09/27

Quoting halostatue@gmail.com, on Tue, Sep 27, 2005 at 10:29:17AM +0900:

[#6015] Re: gems is a language change, not a pkging system — James Edward Gray II <james@...> 2005/09/27

On Sep 26, 2005, at 8:54 PM, Sam Roberts wrote:

[#6016] Re: gems is a language change, not a pkging system — Sam Roberts <sroberts@...> 2005/09/27

Quoting james@grayproductions.net, on Tue, Sep 27, 2005 at 11:06:01AM +0900:

[#6018] Re: gems is a language change, not a pkging system — Austin Ziegler <halostatue@...> 2005/09/27

On 9/26/05, Sam Roberts <sroberts@uniserve.com> wrote:

[#6019] Re: gems is a language change, not a pkging system — Sam Roberts <sroberts@...> 2005/09/27

Quoting halostatue@gmail.com, on Tue, Sep 27, 2005 at 11:49:14AM +0900:

[#6024] Re: gems is a language change, not a pkging system — Austin Ziegler <halostatue@...> 2005/09/27

On 9/27/05, Sam Roberts <sroberts@uniserve.com> wrote:

[#6025] Re: gems is a language change, not a pkging system — Ralph Amissah <ralph.amissah@...> 2005/09/27

> Right now, they're watching people who have pretty much sat on the side

[#6026] Re: gems is a language change, not a pkging system — Austin Ziegler <halostatue@...> 2005/09/27

On 9/27/05, Ralph Amissah <ralph.amissah@gmail.com> wrote:

[#6043] Re: gems is a language change, not a pkging system — Ralph Amissah <ralph.amissah@...> 2005/09/28

I'll greatly weaken my post, and give everyone the opportunity to head me

[#6044] Re: gems is a language change, not a pkging system — Hugh Sasse <hgs@...> 2005/09/28

On Wed, 28 Sep 2005, Ralph Amissah wrote:

[#6073] Re: gems is a language change, not a pkging system — Mauricio Fern疣dez <mfp@...> 2005/09/28

Hello,

[#6074] Re: gems is a language change, not a pkging system — Jim Weirich <jim@...> 2005/09/29

On Wednesday 28 September 2005 07:35 pm, Mauricio Fern疣dez wrote:

[#6017] Re: gems is a language change, not a pkging system — Austin Ziegler <halostatue@...> 2005/09/27

On 9/26/05, Sam Roberts <sroberts@uniserve.com> wrote:

[#6046] Re: gems is a language change, not a pkging system — "Sean E. Russell" <ser@...> 2005/09/28

On Monday 26 September 2005 22:41, Austin Ziegler wrote:

[#6050] Re: gems is a language change, not a pkging system — Hugh Sasse <hgs@...> 2005/09/28

On Wed, 28 Sep 2005, Sean E. Russell wrote:

[#6207] Re: gems is a language change, not a pkging system — "Sean E. Russell" <ser@...> 2005/10/10

On Wednesday 28 September 2005 08:54, Hugh Sasse wrote:

[#6045] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — "Sean E. Russell" <ser@...> 2005/09/28

On Monday 26 September 2005 21:29, Austin Ziegler wrote:

[#6048] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Austin Ziegler <halostatue@...> 2005/09/28

On 9/28/05, Sean E. Russell <ser@germane-software.com> wrote:

[#6059] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Dominique Brezinski <dominique.brezinski@...> 2005/09/28

On 9/28/05, Austin Ziegler <halostatue@gmail.com> wrote:

[#6061] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Austin Ziegler <halostatue@...> 2005/09/28

On 9/28/05, Dominique Brezinski <dominique.brezinski@gmail.com> wrote:

[#6062] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — Dominique Brezinski <dominique.brezinski@...> 2005/09/28

For what it is worth, I live life behind an authenticated proxy, so I

[#6099] Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem) — "Sean E. Russell" <ser@...> 2005/09/30

On Wednesday 28 September 2005 08:43, Austin Ziegler wrote:

[#6009] Re: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault — Ralph Amissah <ralph.amissah@...>

(i) correction, segfault is with official ruby 1.8.3 (2005-09-21), not

21 messages 2005/09/27
[#6010] Fwd: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault — Ralph Amissah <ralph.amissah@...> 2005/09/27

[sorry for duplicate post]

[#6079] Re: Fwd: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault — ts <decoux@...> 2005/09/29

>>>>> "R" == Ralph Amissah <ralph.amissah@gmail.com> writes:

[#6081] Re: Fwd: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault — ts <decoux@...> 2005/09/29

>>>>> "t" == ts <decoux@moulon.inra.fr> writes:

[#6082] Re: Fwd: ruby 1.8.3 (2005-09-21) [i486-linux] sisu segfault — Tanaka Akira <akr@...17n.org> 2005/09/29

In article <200509291419.j8TEJYid015419@moulon.inra.fr>,

Question about cgi.rb's read_multipart method and possible fix

From: "Zev Blut" <rubyzbibd@...>
Date: 2005-09-29 07:02:00 UTC
List: ruby-core #6076
Hello,

My colleagues and I have discovered a potential problem with the
implementation of the CGI library's read_multipart method.  The
current CGI implementation will create a temporary file for many of
the multipart data entries if the posted content length is greater
than 10 kilobytes.

I would like to ask what is the intended goal of the implementation?
Is the goal to make temporary files for each data entry that is more
than 10 kilobytes and keep entries that are less in StringIO objects?

The reason I ask is that the current implementation works in a
different way.  It will create temporary files for each data entry
until the remaining content data stream is less than 10 kilobytes.
Then it will use StringIO for the remaining entries.

This implementation turns out to have disastrous consequences for some
of my applications.  We have some situations where we send images and
many select options in a post.  This ends up creating hundreds and
sometimes thousands of Tempfiles, which causes our servers to become
unresponsive.

I have modified read_multipart to only create TempFiles for each data
entry greater than 10 kilobytes.  With this modification our servers
are responsive and show no other problems with my change.

I have made a few other changes to the implementation to use sub!
method calls to hopefully remove unneeded duplication of large buffers.
I dug through the CVS history and it appears it was originally using
such a sub! call, but later when to "buf = buf.sub" calls, is there a
reason why?  If so I will revert back to "buf = buf.sub".

Ignoring a few minor style changes in my implementation and or my
implementation all together, the main point of discussion I would like
to start is if the current 10 kilobyte implementation is correct of if
the intended goal of my modification is correct?  If my modification
is not too offensive I can integrate it with cgi.rb and post a patch.

Best Regards,
Zev Blut

Attachments (1)

CGIFIX.rb (3.75 KB, text/x-ruby)
# This is a quick fix to change CGI's read_mutipart method to not
# create lots of small Tempfiles.  It will now only create Tempfiles
# for data entries that are larger than 10KB.

class CGI

  module QueryExtension

    def read_multipart(boundary, content_length)
      params = Hash.new() { |h,k| h[k] = Array.new }
      boundary = "--" + boundary
      buf = ""
      bufsize = 10240 # 10KB

      # start multipart/form-data
      stdinput.binmode if defined? stdinput.binmode
      boundary_size = boundary.size + EOL.size
      content_length -= boundary_size

      status = stdinput.read(boundary_size)
      if nil == status
        raise EOFError, "no content body"
      elsif boundary + EOL != status
        raise EOFError, "bad content body"
      end

      loop do
        head = nil
        body = MorphingBody.new

        until head and /#{boundary}(?:#{EOL}|--)/n.match(buf)

          if (not head) and /#{EOL}#{EOL}/n.match(buf)
            buf.sub!(/\A((?:.|\n)*?#{EOL})#{EOL}/n) do
              head = $1.dup
              ""
            end
            next
          end

          if head and ( (EOL + boundary + EOL).size < buf.size )
            body.print buf[0 ... (buf.size - (EOL + boundary + EOL).size)]
            buf[0 ... (buf.size - (EOL + boundary + EOL).size)] = ""
          end

          # should be c = if, but changed for broken emacs indent
          if bufsize < content_length
            c = stdinput.read(bufsize)
          else
            c = stdinput.read(content_length)
          end

          if c.nil?
            raise EOFError, "bad content body"
          end
          buf.concat(c)
          content_length -= c.size
        end

        # change to ! to remove excessive object creation
        buf.sub!(/\A((?:.|\n)*?)(?:[\r\n]{1,2})?#{boundary}([\r\n]{1,2}|--)/n) do
          body.print $1
          if "--" == $2
            content_length = -1
          end
          ""
        end

        body = body.extract
        body.rewind

        /Content-Disposition:.* filename="?([^\";]*)"?/ni.match(head)
        filename = ($1 or "")
        if /Mac/ni.match(env_table['HTTP_USER_AGENT']) and
            /Mozilla/ni.match(env_table['HTTP_USER_AGENT']) and
            (not /MSIE/ni.match(env_table['HTTP_USER_AGENT']))
          filename = CGI::unescape(filename)
        end

        /Content-Type: (.*)/ni.match(head)
        content_type = ($1 or "")

        (class << body; self; end).class_eval do
          alias local_path path
          define_method(:original_filename) {filename.dup.taint}
          define_method(:content_type) {content_type.dup.taint}
        end

        /Content-Disposition:.* name="?([^\";]*)"?/ni.match(head)
        name = $1.dup

        params[name].push(body)
        break if buf.size == 0
        break if content_length == -1 # removed === ?
      end

      params
    end # read_multipart

    require "stringio"
    require "tempfile"

    # A wrapper class to use a StringIO object as the body and switch
    # to a TempFile when the passed threshold is passed.
    class MorphingBody

      def initialize(morph_threshold = 10240)
        @threshold = morph_threshold
        @body = StringIO.new
        @cur_size = 0
        @morph_check = true

        @body.binmode if defined? @body.binmode
      end

      def print(data)
        if @morph_check && (@cur_size + data.size > @threshold)
          convert_body
        end
        @body.print data
      end

      # returns the true body object.
      def extract
        @body
      end

      private
      def convert_body
        new_body = TempFile.new("CGI")
        new_body.binmode if defined? new_body.binmode

        @body.rewind
        new_body.print @body.read
        @body = new_body
        @morph_check = false
      end
    end

  end

end

In This Thread

Prev Next