InfoPath as a client doesn't respect the session cookie. You'll have to
receive the web service through script and store the header information into
the DOM somewhere, and handle the cookie get/send yourself. Sorry I don't
have any more information on how to do this, but at least you can stop
looking for something automatic within InfoPath.
Brian
> *Please* help --- I'm tearing my hair out.
>
[quoted text clipped - 22 lines]
>
> I'm lost & frustrated...
Brian,
Thanks for the reply.
Is it possible you're wrong, or I'm *totally* misunderstanding what's going
on? 'Coz now I'm even *more* mystified!
First, forget about SOAP. I think I understand I'm talking about HTTP
headers.
I'm finding, empirically, that my session & state *are* being preserved,
even though I've done nought in InfoPath! Yet you say:
> InfoPath as a client doesn't respect the session cookie.
Debugging at the webservice side, I see a session being created for the
first IP request. Then no new session for subsequent requests, and my WS
sees its Session[] variables as it set them up last request. Session times
out as usual after inactivity for a while, as per web.config.
I switch on debugging in IIS to include showing "cookies". For all requests
(after the first) coming in from IP I see at the end of the trace info all
the "cookies", *including* "ASP.NET_SessionId=......." at the end.
This is being passed from IP, right? And the fact it's there is causing the
WS to reuse existing session, right? What am I failing to understand? I
find *all* IP sessions on my machine (no matter what IP form), to the same WS
at least, use the same WS session; any IP sessions from another machine use a
different session.
Maybe I'm not very clear about what I'm wanting/trying to understand. There
are really 2 different things, I don't quite understand how they are related:
1. My WS must see the same session for subsequent requests from the same IP
client (machine will probably do), as indicated by when Session_Start() in
Global.asax.cs gets called. I find this is true. This is vital.
2. My WS sees the same variables/contents in its Session[] bucket for
subsequent requests from the same IP client (machine will probably do). I
find this is true. This is *not* so vital, so long as I know what the case
will be --- I can code as necessary.
I should be *so* grateful if you/whoever would explain.
> InfoPath as a client doesn't respect the session cookie. You'll have to
> receive the web service through script and store the header information into
[quoted text clipped - 30 lines]
> >
> > I'm lost & frustrated...
Matthew Blain \(Serriform\) - 30 Nov 2004 21:30 GMT
I expect you'll have to add the session as a paremeter in the web service
methods. InfoPath is probably relying on something underneath which assumes
that HTTP is stateless, and any shared info can safely be shared across all
calls on the machine--possibly including IE and multiple InfoPath forms.
I have no idea what InfoPath does internally, but this might be a feature
request for future versions. But the inherent statelessness of HTTP means
that relying on sessions may not be such a good idea. Since cookies are not
really part of SOAP (I don't think, I may be wrong), a client can choose to
implement cookie handling any way it wants and still be a perfectly valid
Web Service client.
--Matthew Blain
http://tips.serriform.com/
http://www.developingsolutionswithinfopath.com
> Brian,
>
[quoted text clipped - 72 lines]
> > >
> > > I'm lost & frustrated...
jb - 01 Dec 2004 13:43 GMT
Matthew,
If you're interested, see my response to Brian above. Thanks for your help.
"Matthew Blain (Serriform)" wrote:
> I expect you'll have to add the session as a paremeter in the web service
> methods. InfoPath is probably relying on something underneath which assumes
[quoted text clipped - 109 lines]
> > > >
> > > > I'm lost & frustrated...
Dan Rogers - 30 Nov 2004 21:33 GMT
Hi JB,
It's confusing to me whether your issues are solved or not. If session is
working, is there still a problem?
Regards
Dan Rogers
Microsoft Corporation
--------------------
>Thread-Topic: WebService session sessionstate SOAP
>thread-index: AcTW+tPoi/E9wHG1QWaCZb+6c/gMUA==
>X-WBNR-Posting-Host: 82.152.32.104
>From: "=?Utf-8?B?amI=?=" <jb@discussions.microsoft.com>
>References: <D508185A-92F1-4EAE-9997-531792C3D9DA@microsoft.com>
<#YCgSyn1EHA.412@TK2MSFTNGP14.phx.gbl>
>Subject: Re: WebService session sessionstate SOAP
>Date: Tue, 30 Nov 2004 08:37:05 -0800
[quoted text clipped - 10 lines]
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
>Newsgroups:
microsoft.public.xml.soap,microsoft.public.dotnet.framework.aspnet.webservic
es,microsoft.public.dotnet.framework.webservices,microsoft.public.infopath
>NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
>Path:
cpmsftngxa10.phx.gbl!TK2MSFTFEED01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGXA0
3.phx.gbl
>Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.aspnet.webservices:26892
microsoft.public.dotnet.framework.webservices:7696
microsoft.public.infopath:14431 microsoft.public.xml.soap:7295
>X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
>
[quoted text clipped - 74 lines]
>> >
>> > I'm lost & frustrated...
jb - 01 Dec 2004 11:17 GMT
From my investigations, session is working the way I would like, and so my
issues are solved (if a bit worryingly...)
This is now an "InfoPath" issue, and I will continue my comments in that
forum. Thanks for your interest.
> Hi JB,
>
[quoted text clipped - 134 lines]
> >> >
> >> > I'm lost & frustrated...
jb - 01 Dec 2004 11:17 GMT
From my investigations, session is working the way I would like, and so my
issues are solved (if a bit worryingly...)
This is now an "InfoPath" issue, and I will continue my comments in that
forum. Thanks for your interest.
> Hi JB,
>
[quoted text clipped - 134 lines]
> >> >
> >> > I'm lost & frustrated...