Rails 会话是否可以“及时”创建？
我对 Ruby on Rails（特别是 v3 及更高版本）中会话生命周期的理解是，在请求开始时为每个请求创建一个会话，如果该请求不携带现有会话 cookie，则创建一个新会话将被创建，否则会话 cookie 将被反序列化并存储在会话哈希中。
当然，这样做的目的是支持许多安全功能，例如 CSRF 等。
但是，当涉及到具有 HTTP 缓存服务和代理（例如 Varnish）的站点中的页面缓存时，这会带来一些问题，因为大多数配置的某些部分倾向于在请求端和响应端去除这些（通常是所有）cookie（因为缓存通常是针对一般受众的）。
我知道可以设置 Varnish 等来创建包含 cookie 详细信息的对象哈希，这会将缓存数据的范围限制到该会话（以及该用户），但是我想知道这是否完全必要。
我有一个本质上相当“静态”的应用程序 - 内容从数据库中提取，呈现到一个页面中，然后可以缓存 - 有一些元素（例如评论计数、“最近”项目等）可以是添加到 ESI 中，但是对于每个请求，Rails 仍然倾向于设置一个新会话，并且当用户已经有一个会话时，这些东西会被缓存服务器删除。
我想知道是否有可能（通过预先存在的功能，或自己构建功能）允许开发人员控制何时需要会话，并且只有在指定时才可以使用 cookie、会话进行后退和前进初始化/反序列化等必要。
那，或者我以错误的方式思考这个问题，需要从另一个角度解决这个问题......
My understanding of the session lifecycle in Ruby on Rails (specifically v3 and upwards) is that a session is created at the start of a request, for each and every request, and if that request doesn't carry an existing session cookie a new one will be created, otherwise the session cookie is deserialized and stored in the session hash.
The purpose of this, of course, supports a number of security features such as CSRF etc.
However, this poses a bit of an issue when it comes to caching of pages in a site with HTTP cache services and proxies such as Varnish, as most of the configurations tend to strip out these (generally all) cookies on both the request and response end (as the cache is usually intended for a generalized audience).
I know that it is possible to setup Varnish etc to create the object hash with the cookie details included, and this would scope the cached data to that session (and therefor that user), however I am wondering if this is completely necessary.
I have an application which is fairly 'static' in nature - content is pulled from a database, rendered into a page which can then be cached - there are a few elements (such as comment count, 'recent' items etc) which can be added in with an ESI, but for every request Rails still tends to want to setup a new session, and when a user already has a session this stuff is stripped out by the cache server.
I am wondering if it might be possible (via pre-existing functionality, or building the functionality myself) to allow the developer to control when a session is required, and only when that is specified is the back-and-forwards with cookies, session initialization/deserialization etc necessary.
That, or I am thinking about this problem the wrong way and need to address the issue from another angle...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
据我所知，rails 会话可以通过 ActionController::SessionManagement
http://ap.rubyonrails.org/classes/ActionController/SessionManagement/ClassMethods.html#M000070
API 文档中有针对每个操作、每个控制器等禁用它的示例。
From what I know rails sessions can be controlled fairly in-depth via ActionController::SessionManagement
http://ap.rubyonrails.org/classes/ActionController/SessionManagement/ClassMethods.html#M000070
There are examples in the API docs of disabling it per action, per controller, etc.
如果您的网站大部分是静态的，那么您可能需要使用全页缓存。这会将 Rails 完全排除在请求之外，并让 Web 服务器在生成内容后处理它。可能会引起一些严重的头痛，具体取决于您的具体需求，就评论数量和用户具体情况而言。
If your site is mostly static then you may want to use full page caching. This takes Rails out of the request entirely and let's the web server deal with it once the content has been generated. Might cause some serious headaches depending on your exact needs as far as the comment counts and user-specifics though.