rack-devel archive mirror (unofficial) https://groups.google.com/group/rack-devel
 help / color / mirror / Atom feed
From: Eric Wong <normalperson@yhbt.net>
To: rack-devel@googlegroups.com
Subject: Re: [PATCH 0/3] support reuse of HeaderHash objects
Date: Tue, 5 Jan 2010 15:58:45 -0800	[thread overview]
Message-ID: <20100105235845.GB3377@dcvr.yhbt.net> (raw)
In-Reply-To: <1252100514-2748-1-git-send-email-normalperson@yhbt.net>

Eric Wong <normalperson@yhbt.net> wrote:
> HeaderHash objects are needlessly created and discarded by various
> pieces of Rack middleware, leading to unnecessary overhead
> from both object creation + GC and iteration overhead via
> headers#each.

Ugh, this series interacts badly with applications and frameworks that
set cookies without using Rack::Utils.  Rails 2.3.5 is one (popular)
example of a framework that sets cookies without help from Rack::Utils.

Below is a patch (against Rails 2.3.5) that pinpoints and fixes the
problematic code:  (I don't expect this patch to be applied)

diff --git a/actionpack/lib/action_controller/session/abstract_store.rb b/actionpack/lib/action_controller/session/abstract_store.rb
index f6369ab..2df45d8 100644
--- a/actionpack/lib/action_controller/session/abstract_store.rb
+++ b/actionpack/lib/action_controller/session/abstract_store.rb
@@ -144,8 +144,9 @@ module ActionController
           cookie << "; HttpOnly" if options[:httponly]
           headers = response[1]
-          unless headers[SET_COOKIE].blank?
-            headers[SET_COOKIE] << "\n#{cookie}"
+          set_cookie = headers[SET_COOKIE]
+          unless set_cookie.blank?
+            set_cookie << (Array === set_cookie ? cookie : "\n#{cookie}")
             headers[SET_COOKIE] = cookie

Without the above patch, I end up with a blank cookie with nothing in it
when (using Unicorn):

  Set-Cookie: set_by_app=cookie-1715-; path=/
  Set-Cookie: _session_cookie=98e3f12545e70a6b7a943628a3a7578b; path=/; HttpOnly

This was because Rails was blindly prepending "\n" to the cookie thinking
it's hitting a string, but the value of headers[SET_COOKIE] is now an

Below is a potential fix to Rack to fix the problem, but I'm not sure
about the severity of this problem with real HTTP clients (other than 12

diff --git a/lib/rack/utils.rb b/lib/rack/utils.rb
index 68fd6ac..10dc8fe 100644
--- a/lib/rack/utils.rb
+++ b/lib/rack/utils.rb
@@ -273,19 +273,23 @@ module Rack
         hash.each { |k, v| self[k] = v }
+      def value_string(v)
+        if v.respond_to?(:to_ary)
+          v = v.to_ary.join("\n")
+          v.gsub!(/\n\n+/, "\n")
+        end
+        v
+      end
       def each
         super do |k, v|
-          yield(k, v.respond_to?(:to_ary) ? v.to_ary.join("\n") : v)
+          yield(k, value_string(v))
       def to_hash
         inject({}) do |hash, (k,v)|
-          if v.respond_to? :to_ary
-            hash[k] = v.to_ary.join("\n")
-          else
-            hash[k] = v
-          end
+          hash[k] = value_string(v)

There's also a one-line fix that I could make to Unicorn by replacing
split(/\n/) with split(/\n+/), which may be a good idea anyways in case
frameworks/apps attempt more "creative" ways to set other headers...

Eric Wong

      parent reply	other threads:[~2010-01-05 23:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-04 21:41 [PATCH 0/3] support reuse of HeaderHash objects Eric Wong
2009-09-04 21:41 ` [PATCH 1/3] HeaderHash.new avoids unnecessary object creation Eric Wong
2009-09-04 21:41 ` [PATCH 2/3] avoid HeaderHash#to_hash in middlewares Eric Wong
2009-09-04 21:41 ` [PATCH 3/3] CommonLogger uses HeaderHash to lookup Content-Length Eric Wong
2009-09-28 10:14 ` [PATCH 4/3] HeaderHash#each yields Lint-OK multivalue headers Eric Wong
2010-01-05 23:58 ` Eric Wong [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://groups.google.com/group/rack-devel

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100105235845.GB3377@dcvr.yhbt.net \
    --to=rack-devel@googlegroups.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).