tags:

views:

406

answers:

0

I am trying to implement session between WCF and gSoap, using basicHttpBinding. And I've almost succeeded, using ASP.NET compatibility mode. I used this technique: http://blogs.msdn.com/sajay/archive/2006/08/03/687361.aspx

Now, while I used a .NET client for my service, everyting just worked fine. Then I tried the same with gSOAP. I made my proxy for SOAP 1.1 and compiled stdsoap2.cpp with

#define WITH_COOKIES

to allow session cookies. But still I received new session ID per each call.

So I investigated this issue, and here is what I found. The client DOES receive the ASP.NET session cookie! But he also receives another strange cookie with the following parameters:

- Name = "HttpOnly" (no, the HttpOnly property is set to "false", but the cookie's NAME is "HttpOnly"!)

- Domain = "localhost"

- Path = "Service1.svc" (this is the WCF service I've called)

- Value = NULL

So, as I said, two cookies come to the client, so I can find them in soap.cookies structure: the first is ASP.NET session cookie and the second is that strange cookie above. On the next call gSoap sends both cookies to WCF, and if I put a breakpoint in WCF service, I see that Request.Cookies[0] is that strange cookie and then Request.Cookies[[1]] is ASP.NET session cookie (gSoap sends them in reverse order, this is perhaps just its implementation detail) . Perhaps this is what confuses ASP.NET, so he starts a new session instead of identifying the existing one.

So I can solve it this way. soap.cookies is the linked list. I can just remove this strange cookie like that:

soap.cookies->next = NULL;

There is a memory leak here, but nevermind - this is just an example. And it works! Now I have the same session ID assigned for the next call, and the session just works fine! The question is: what is that strange cookie? Where does it come from?

related questions