axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Illsley (JIRA)" <>
Subject [jira] Commented: (AXIS2-1376) Use of ReplyTo in session mechanism considered harmful
Date Mon, 16 Oct 2006 10:33:35 GMT
    [ ] 
David Illsley commented on AXIS2-1376:


With regards to using the anonymous address, I believe that Brian changed that recently so
that in the 2005/08 case the none URI is used (as anonymous is definately wrong). This change
was not made for 2004/08 as its equivalent of the none uri is to not have an EPR, which is
problematic when trying to deal with Reference Parameters :-)

Also, a concrete URI is not correct as there may be multiple services within a ServiceGroup
(which I believe is covered by the session mechanism) which thereforre have different Request
URI values so just sending back the previously used address is not necessarily correct (and
in fact the EPR address is currently ignored in the client).

I agree that the use of ReplyTo in a response message is not defined and that it would be
cleaner to use a different header.

That said, I'm not sure that inventing something totally separate from WS-Addressing is necessary
or particularly useful.

My suggestion would be to define a custom relationship type which would be sent back on the
response message and which the client would then copy to subsequent requests.

> Use of ReplyTo in session mechanism considered harmful
> ------------------------------------------------------
>                 Key: AXIS2-1376
>                 URL:
>             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