是否可以使用 NSURLConnection 执行不同的请求来保持会话活动？
我正在使用 NSRULConnection 在我的 iphone 应用程序上发出 http 请求。一切都很好。
问题是登录后我需要保持相同的会话才能从服务器获取数据。
我读了一些帖子，说我需要的是使用相同的 NSURLConnection 实例，并且它将使用相同的会话...如果这是真的，那对我来说没有意义，因为 NSURLConnection 不可变并且没有方法来更改请求，因为我必须访问不同的页面。
有没有简单的方法来使用 NSURLConnection 保持会话。
I am using NSRULConnection to make http request on my iphone application. All works just fine.
The problem is after logged in I need to keep the same session to get data from the server.
I read a few posts saying all I need was using the same instance of NSURLConnection and it would use the same session... if that is true, that doesn't make sense to me, cause the NSURLConnection is not mutable and there is no method to change the request since I have to access different pages.
Is there anyway simple way to keep a session using NSURLConnection.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您使用 cookie 管理会话，则无需执行任何特殊操作即可实现会话管理。URL 加载系统 自动发送任何存储的适合NSURL请求。除非请求指定不发送cookie。因此，您的会话应该自动为您管理。
然而，正如苹果公司的文档所说，如果有人将 cookie 接受策略设置为拒绝所有 cookie 或仅选择性地接受 cookie，那么您可能会遇到问题（您也可以自己更改 cookie 接受策略）。在这种情况下，您可能会求助于基于 URL 的会话管理；其中，您将会话标识符作为参数附加到 URL（您可以在成功登录响应中获取此标识符），该标识符可以在服务器端提取。然而，这被认为是非常糟糕的做法。
我更经常遇到的另一种方法是获取会话标识符作为成功登录响应的一部分，并将该标识符作为参数包含在所有后续请求中。尽管这需要对服务器处理会话的方式进行重大更改。
If you are managing sessions using cookies, there is no need to do anything special to achieve session management.The URL loading system automatically sends any stored cookies appropriate for an NSURLRequest. unless the request specifies not to send cookies. So, your sessions should be managed automatically for you.
However, as the Apple's doc says, if someone has set the cookie-acceptance policy to reject all cookies or only accept cookies selectively, you might be in a fix (you can change the cookie acceptance policy yourself too). In such a case, you might resort to URL based session-management; in which you append a session-identifier to the URL as a parameter (You can get this identifier as a part of the successful log-in response), which can be extracted on the server-side. This, however, is considered really bad practice.
Another way, which I have come across more often, is to get a session-identifier as part of the response for a successful log-in and include that identifier in all your subsequent requests as a parameter. Although this would require a major change in the way the server handles the sessions.