Permalink
Browse files

CookieStore should preserve the Set-Cookie header Array [#4743 state:…

…resolved]

Signed-off-by: Jeremy Kemper <jeremy@bitsweat.net>
  • Loading branch information...
1 parent 5ed6a84 commit 85b6d79d8a17fdef667770e31b44ac6647f8b584 @jstorimer jstorimer committed with jeremy Jun 1, 2010
@@ -114,11 +114,8 @@ def call(env)
end
cookie = build_cookie(@key, cookie.merge(options))
- unless headers[HTTP_SET_COOKIE].blank?
- headers[HTTP_SET_COOKIE] << "\n#{cookie}"
- else
- headers[HTTP_SET_COOKIE] = cookie
- end
+ headers[HTTP_SET_COOKIE] = [] if headers[HTTP_SET_COOKIE].blank?
+ headers[HTTP_SET_COOKIE] << cookie
end
[status, headers, body]
@@ -44,6 +44,12 @@ def raise_data_overflow
head :ok
end
+ def set_session_value_and_cookie
+ cookies["foo"] = "bar"
+ session[:foo] = "bar"
+ render :text => Rack::Utils.escape(Verifier.generate(session.to_hash))
+ end
+
def rescue_action(e) raise end
end
@@ -96,7 +102,7 @@ def test_setting_session_value
with_test_route_set do
get '/set_session_value'
assert_response :success
- assert_equal "_myapp_session=#{response.body}; path=/; HttpOnly",
+ assert_equal ["_myapp_session=#{response.body}; path=/; HttpOnly"],
headers['Set-Cookie']
end
end
@@ -164,7 +170,7 @@ def test_setting_session_value_after_session_reset
get '/set_session_value'
assert_response :success
session_payload = response.body
- assert_equal "_myapp_session=#{response.body}; path=/; HttpOnly",
+ assert_equal ["_myapp_session=#{response.body}; path=/; HttpOnly"],
headers['Set-Cookie']
get '/call_reset_session'
@@ -193,6 +199,14 @@ def test_persistent_session_id
end
end
+ def test_setting_session_value_and_cookie
+ with_test_route_set do
+ get '/set_session_value_and_cookie'
+ assert_response :success
+ assert_equal({"_myapp_session" => response.body, "foo" => "bar"}, cookies)
+ end
+ end
+
private
def with_test_route_set
with_routing do |set|

10 comments on commit 85b6d79

Member

josh replied Oct 26, 2010

Header values should never be an Array. We should revert this.

Contributor

jstorimer replied Oct 27, 2010

Agreed, we should go the other direction and always force it to be a string. I'll write a patch.

Owner

pixeltrix replied Oct 27, 2010

Rather than just patch it up everywhere we should probably refactor the session code so that it goes through the CookieJar rather than writing out the session cookie directly itself. That way we're delegating the cookie handling to Rack, where it should be.

Member

josh replied Oct 27, 2010

I noticed this upgrading an app to 2.3.9 and Rack::Lint went nuts. Most rack servers will still handle legacy Array headers fine so this isn't super critical.

@pixeltrix I extracted some helpers to Rack::Utils awhile back for this reason.

This seems super broken too. We're converting Set-Cookie to an Array on the way out. (I'm sure git blame says I wrote the code too)

Array headers are fine internally as long as we cast them to strings on the way out so other middleware doesn't have to deal with them.

Owner

pixeltrix replied Oct 27, 2010

@josh I saw those and now that 2-3-stable is requiring Rack 1.1 we can use them. I think there's at least three places where cookies are being built so it's ripe for refactoring. This commit needs reverting as well.

Contributor

jstorimer replied Oct 27, 2010

@pixeltrix that commit followed the convention that I set up with this commit. I'll have a look at using set_cookie_header! where possible instead.

Owner

pixeltrix replied Oct 27, 2010

@jstorimer the session stores probably shouldn't be calling set_cookie_header! directly - we should let ActionController::CookieJar do the heavy lifting.

Contributor

josevalim replied Oct 27, 2010

Pixeltrix, the cookie store in Rails master already delegates to the cookie jar. All other stores are coming from Rack (where we can't have any delegation).

The response is also broken in Rails 3. I remember there is a logic to convert the Set-Cookie from an Array to a String and this definitely needs to be fixed as well.

Contributor

boone replied Dec 2, 2010

Is there a ticket in Lighthouse where I can track this issue? Thanks.

Contributor

jstorimer replied Dec 21, 2010

@boone Looks like this was already taken care of in e0eb8e9

Please sign in to comment.