ruby-on-rails - 为什么Rails会不断发回Set-Cookie header ？

Question

我遇到了弹性负载平衡器和清漆缓存方面的问题，这些问题涉及cookie和 session 在 rails 和客户端之间混杂在一起。问题的一部分是，Rails几乎在每个请求上都添加了带有 session ID的“Set-Cookie” header 。如果客户端已经在发送session_id，并且与rails将要设置的session_id相匹配。为什么Rails会不断告诉客户端“哦，是的。您的 session ID是...”

Answer 1

摘要:几乎在每个响应上都设置了 Set-Cookie header ，因为

默认 session 存储将尝试在已访问该 session 的任何请求(从 session 中读取或写入)上将 session 数据写入加密的cookie中，

即使纯文本值不存在，加密的值也会更改，

加密在到达负责检查Cookie值是否已更改的代码之前发生，以避免冗余的Set-Cookie header 。

纯文本Cookie

在Rails中， ActionDispatch::Cookies中间件负责根据 Set-Cookie的内容编写 ActionDispatch::Cookies::CookieJar响应头。

正常的行为是您期望的:如果cookie的值与请求的 Cookie header 中的值相同，并且有效期未更新，则Rails不会在响应中发送新的 Set-Cookie header 。

这是通过 CookieJar#[]=中的条件来解决的，该条件将已经存储在cookie jar中的值与正在写入的新值进行比较。

加密的cookie

为了处理加密的cookie，Rails提供了一个 ActionDispatch::Cookies::EncryptedCookieJar类。
EncryptedCookieJar依靠 ActiveSupport::MessageEncryptor提供加密和解密，每次调用时都会使用随机的 initialisation vector。这意味着即使给定了相同的纯文本字符串，也几乎可以保证返回不同的加密字符串。换句话说，如果我解密我的 session 数据，然后重新加密，我将得到与开始时不同的字符串。
EncryptedCookieJar的功能不是很多:它包装了常规的 CookieJar，并且仅在数据输入时提供加密，而在数据返回时提供解密。这意味着 CookieJar#[]=方法仍然负责检查cookie的值是否已更改，甚至不知道给定的cookie值是否已加密。
EncryptedCookieJar的这两个属性说明了为什么在不更改加密cookie值的情况下设置加密cookie总是会产生 Set-Cookie header 的原因。

session 存储

Rails提供了不同的 session 存储。它们中的大多数将 session 数据存储在服务器上(例如，存储在memcached中)，但是默认的 ActionDispatch::Session::CookieStore使用 EncryptedCookieJar将所有数据存储在加密的Cookie中。
ActionDispatch::Session::CookieStore从 #commit_session?继承了 Rack::Session::Abstract::Persisted方法，该方法确定是否应设置cookie。如果 session 已加载，则答案几乎总是“是的，设置cookie”。

正如我们已经看到的，在 session 已加载但未更改的情况下，我们仍将以不同的加密值(因此是 Set-Cookie header )结束。