Use of ReplyTo in session mechanism considered harmful
------------------------------------------------------
Key: AXIS2-1376
URL: http://issues.apache.org/jira/browse/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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
