Nicholas Lesiecki wrote:
Sorry for another long response cycle, I wanted to get some time to digest the several emails on the topic.
To reiterate, since I'm still holding the ball on implementing this:
The proposed solution is to store the test results in application scope under a test-unique key. (And document Cactus's inability to work with load balancers--which Vincent has already done).
I agree that load balancers should not have any bearing on the code under test. It's often easy to bypass them by sending your requests directly to one of the nodes in a cluster (at least it is where I work). Was there an open bug for this issue that we should close?
Finally, I realize I was being confusing in my original email, I talked about headers in two different contexts:
1) Vincent's (now discarded) solution 2) The unique key solution
I have been trying to get the Cactus code on the server to generate the unique id of the test results and then pass it back to the client in a header before running the test. Since the redirector generates the ids, its easier to make them unique to a given test.
Here is the series of events I envision: When the redirector receives the initial request, it will 1) generate a unique id
2) add the unique id as a header to the http response object a) by adding the unique-id header before the test runs, the client cannot commit the response before the unique-id header is added
3) run the test (and send the response to the client)
4) store the test results in application scope under the unique key
The cactus client would then 1) parse the unique id header
2) generate a second request for the test results, passing the unique id as a parameter
The redirector would then 1) retrieve the results from app scope based using the key that the client passed as a parameter
2) send these results to the client
Does this seem possible or have I overlooked a problem?
This sounds rather quite IMHO. I'd prefer a cookie though (instead of a response-header and a query-string-parameter), as this is a perfect usage scenario for cookies AFAICT.
-- Christopher Lenz /=/ cmlenz at gmx.de
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
