Skip to main content
A
Anonymous
October 9, 2014
Answered

Replaying HTTP traffic to a CF server

  • October 9, 2014
  • 2 replies
  • 686 views

This is a somewhat technical question. I have recorded a bunch of HTTP traffic to my CF application doing actions that I would like to replay at a later time for testing purposes. These recordings involve a user logging into the application followed by the user performing a bunch of actions. In order to replay this traffic accurately I have set up the replayed traffic to adjust its cookies to maintain the session since the session used during the recording will be expired by then.

This approach works fine for 1 client or so, but when I start scaling this up to many clients it starts to fail intermittently. Debugging the replay clients that are failing, I see that the server is generating a new JSESSIONID cookie for each response even though I am sending the proper cookie in the request. On the other hand, for a replay client that works correctly, I see the JSESSIONID cookie staying the same for the entire session. After a while of running many clients using this method the CF server seems unable to accept any replay clients. Restarting the server seems to fix this problem, but then it starts to happen again.

My guess is that this has something to do with the internals of either the CF configuration or the J2EE session configuration. Does anyone with a more detailed knowledge of these applications have an idea of what might be wrong?

    This topic has been closed for replies.
    Correct answer

    Okay I've managed to solve this. Turns out the session reset was coming from a CF error that said Duplicate Session Detected. This was because there was yet another state management variable being passed around in the http message body called DSId. I managed to pull this from the server response and send it for subsequent requests. This seems to have fixed the problem.

    2 replies

    A
    Anonymous
    Correct answer
    October 16, 2014

    Okay I've managed to solve this. Turns out the session reset was coming from a CF error that said Duplicate Session Detected. This was because there was yet another state management variable being passed around in the http message body called DSId. I managed to pull this from the server response and send it for subsequent requests. This seems to have fixed the problem.

    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    October 16, 2014

    Glad to hear you found the solution. Thanks for sharing it with us.

    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    October 10, 2014

    Is there just one application file? How do the various clients interact with the application? Via browsers? If so, is it one client per browser?

    A
    Anonymous
    October 10, 2014

    Let me preface this by saying this is my first time using CF, so my knowledge is very limited.

    As far as my understanding goes there is no application file. I assume you are talking about the application.cfc file in the root directory. All the settings provided are default. I am only testing against one application.

    For interaction, there were two stages to this. In the first stage I set up a proxy to record all http traffic to the CF server using a program called gor (buger/gor · GitHub). I then started interacting with the CF server with a flash client in my browser, and the gor program recorded all traffic into a file. This part runs fine.

    In the second stage I run gor clients a few days later that read the file and just repeat exactly what was sent over the wire including the time delays and everything. With the exception of the "Cookie" header all other http headers are identical for all gor clients. The Cookie header is the only one I adjust to make sure the previously recorded session tokens are not sent. Those will have expired since I am doing this test several days later. Instead I send no cookies with the first request and the CF server responds with a JSESSIONID like normal. I then record this cookie and send it along with the next request and so on - just like browsers would do. This is the stage where the intermittent problem would come in. I start with a freshly restarted CF server and I try this with one client and I see 1 JSESSIONID being sent/recieved for the whole session. Part way through the session I see a CFID and CFTOKEN being generated by the server and I treat these the same as JSESSIONID. This works fine. I see data being input into the database and everything in the exact same way as when I originally recorded. So I try the same with spinning up 20 gor clients and then I start to see the JSESSIONID being changed by the server over and over again for no apparent reason. Since I cannot keep a consistent session, the gor client cannot interact properly with the server because the login event is not tied to the same session.

    I have tried this with 20 gor clients on one server and 20 gor clients on 20 servers with the same result.

    Does this clear up your questions?

    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    October 10, 2014

    The Application.cfc file may or may not solve your immediate problem, however it is a necessary tool in maintaining sessions. It need not be elaborate. Something like this will do:

    Application.cfc

    <cfcomponent>

        <cfscript>

            this.name = "ation_replay";

            this.applicationTimeout = "#createTimespan(1,0,0,0)#";

            this.loginStorage = "session";

            this.sessionManagement = "true";

            this.sessionTimeout = "#createTimeSpan(0,0,30,0)#";

            this.setClientCookies = "true";

         </cfscript>

        <cffunction name="onApplicationStart" returntype="boolean">

            <cfreturn true>

         </cffunction>

    </cfcomponent>

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices