DO NOT REPLY [Bug 23671] New: - Axis 1.1 doen't support multi-cookies

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23671>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23671

Axis 1.1 doen't support multi-cookies

           Summary: Axis 1.1 doen't support multi-cookies
           Product: Axis
           Version: 1.1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Basic Architecture
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: opepin@ctp.com


Scenario : The Axis Webservice as a session scope deploy on weblogic
The client uses setMaintainSession(true);
A filter in front of the AxisServlet set a extra cookie (for load balancing)

* First call 
  * Client header : 
    No cookie sent 
  * Server header: 
    Set-Cookie: JSESSIONID=AAAAAA
    Set-Cookie: LBCOOKIE=BBBBBBB

* Second call
  * Client header : 
     Cookie: JSESSIONID=AAAAAAA(only one cookie set)
  * Server header: 
    Set-Cookie: LBCOOKIE=CCCCCCC (new lb cookie)

* Third call
  * Client header : 
     Cookie: LBCOOKIE=CCCCCCC (only one cookie set this time the other is lost)
  * Server header: 
    Set-Cookie: LBCOOKIE=DDDDDD( new session created)

Problems:
* Only one cookie is stored for each call 
* If a cookie is already stored in the MessageContext, it is deleted by a new 
cookie

Results:
* Statefull services is not working 
* Load balancing is not working 

Bug analysis : 
The HTTPSender (and CommonsHTTPSender) classe stores headers as Hashmap. 
* It does not support multiple Set-Cookie: headers 
* It do not send back multiple cookies. 
The same way for the MessageContext that stores the "cleaned" cookies as a 
HashMap. 
* Old cookie is deleted (JSESSIONID), if a new cookie is send (LBCOOKIE) on a 
next call 

PS: This bug has been fixed on SOAP 2.3.1 some time ago