axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels (JIRA)" <>
Subject [jira] Created: (AXIS2-1376) Use of ReplyTo in session mechanism considered harmful
Date Fri, 13 Oct 2006 16:10:34 GMT
Use of ReplyTo in session mechanism considered harmful

                 Key: AXIS2-1376
             Project: Apache Axis 2.0 (Axis2)
          Issue Type: Bug
          Components: core
    Affects Versions: 1.1
            Reporter: Glen Daniels
         Assigned To: Glen Daniels

The Axis2 session mechanism currently works by sending back a <wsa:ReplyTo> header on
the RESPONSE of a request/response exchange.  The EPR inside contains a reference parameter
which is the session ID (really the service group ID).  Two problems with this, both regarding
interoperability and cleanliness:

1) We're sending the anonymous URI as the address in the EPR - this could be very confusing
to others, since it usually means the backchannel (i.e. the HTTP response for req/resp) and
in this case we intend it to mean "the same address you used to get to me last time".

2) We shouldn't be using <ReplyTo> for this purpose.  In order for this to work, the
client receiving the EPR in the response needs to understand what it means and what to do
with it (store the RefP "cookie" and send it back next time).  ReplyTo has a clear semantic
in getting responses to work in the context of req/resp, but it's meaning when received ON
a response is not specified anywhere.  As such this is a custom usage which will not interoperate
with anyone else unless they choose to do the same semantic.  That being the case, I would
much rather have a custom <NewEPR> or <RedirectTo> header which we can define
clear and crisp semantics for, instead of overloading an existing one in new ways.

My proposal is to introduce <NewEPR> or <RedirectTo>, use that instead for sending
session cookies, and to use a real URI instead of anonymous.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message