The use of conventional sessions have always been disabled in RIFE and data has always been passed along the datalinks by using the query string or form post parameters. It has been explained in detail why regular sessions are discouraged and how we managed to offer many of their benefits with a minimum of the drawbacks.

RIFE already provides facilities to handle the data flow of an application by setting up the required datalinks in the site structure. You're not actually interested in storing data explicitly in the session, you're however interested in the fact that the data and the state isn't transferred through the client-side but remains on the server. Therefore, we added a configurable state storage mechanism and implemented one for the query string and one for the session; others can easily be added later (database, LDAP, ...). To indicate that you want data to be stored elsewhere, you simple declare state boundaries in the site structure.

For example:

<state store="session">
    <element id="SOURCE" file="element/source.xml" url="/source">
        <flowlink srcexit="exit1" destid="DESTINATION"/>

        <datalink srcoutput="output1" destid="DESTINATION" destinput="input2"/>
        <datalink srcoutput="output2" destid="DESTINATION" destinput="input1"/>
    </element>
    <element id="DESTINATION" file="element/destination.xml" url="/destination"/>
</state>

When you generate an URL for this exit you'll not see query string parameters for the transferred data, but a stateid parameter instead. This refers to a unique identifier that RIFE will use to look up the corresponding state. The identifier changes at each request, so people can still use the back button and follow alternative application paths. This ensures also that each URL still corresponds to one particular point in the application and the state can never get out of sync.

The default state store is still in the query string, but you have the possibility to use it explicitly when you're inside a session storage part and still want to have some data transferred through the client-side. You can freely nest state storage specifications and they will even work across groups and sub-sites.