I found that when using _cprequest.run, even if a cookie is already attached to the request object, the cookie is still blown away. This patch causes it to check if a cookie is already there, and keep the preexisiting cookie if it exists, else the old behavior takes over.
Imagine a scenario where a user logs into a web page, he passes in a
username / password, and is handed back an authentication token(in the form
of a cookie). On the subsequent request, the user includes the token in his
request to indicate to the server that he is currently logged in. Without
this pull request, it is impossible to ever attach a cookie on an outgoing
request because it always attaches a fresh blank cookie just before sending
off. This PR provides the user the ability to choose whether or not to
attach a cookie to their request.
dimdog, I'm afraid I'm not following (probably due to my lack of experience in the code base). It sounds like from what you're describing, cookies wouldn't work at all in CherryPy. I'm certain that's not the case, so help me bridge the gap.
Can you provide an example that demonstrates what you're trying to accomplish? Alternatively (and perhaps even better) would be to provide a test in the suite that captures the use case, failing without your patch, and passing with it.
I forked cherrypy a while ago to incorporate this change, though obviously I would like to not be on my own fork that is growing more and more out of date.
The scenario this came up in is when I was testing code, and I was using the CherryPy request object to communicate with a cherryPy server. I would log in, get handed back a cookie on the response, then try to include the cookie in my new request - showing that I was logged in, essentially - and it would always be overridden by SimpleCookie's default values. This change is designed to allow, if you want, to set a cookie on a request object before firing it off.
Does that make sense? Essentially, without this change, I couldn't make an authenticated request.