All, just some additional thoughts regarding the session topic. Not only technical but also more "social behaviour" abot the topic.
IMO the idea to have the client handle transport sessions by default if the server demands it could be a good idea. I specifically said _could_ because I've some concerns about - privacy - technical reasons Privacy: Web services will be used more and more, become ubiquitous as browsers are today. Enabling the client to handle e.g. cookies by default would also enable the server to switch it on/off and use it. The user of the client isn't even aware about this fact. Thus a server may track the client's behaviour. This is the reason why all modern browsers allow a user to control "sessions" (cookies). IMO this should be true for webservices - let the programmer/user decide if the client needs or supports sessions or not. If they are switched on by default then issue a warning in big red letters. Technical reasons: If a service needs a session, even a transport session, then there must be technical reasons behind this requirement. Then it is expected that the client needs to contact the server more than once and the server needs to identify the client or needs to know that the client called again. This is a specific behaviour of the client - calling a service more than once and the need to be identified by the service. In this case the designer/programmer/user of the client can switch on sessions explicitly. In all other cases sessions aren't needed and could be "exploited" by malicious servers -see remark above. Regards, Werner Sanjiva Weerawarana wrote: > On Sat, 2005-12-31 at 07:29 +0000, Paul Fremantle wrote: > >>I know I'm late :) >> >>Here are my views: >> >>1) Server sessions should be enabled by actual specific action of a >>developer or deployer >> >>2) Client sessions should be enabled by the following model: >> a) If the programmer repeatedly uses the same instance of the same >>stub then sessions will be *possible*. >> b) Only if the server uses HTTP cookies or WS-A reference params >>the session will be *actual*. >> >>i.e. for a session to take place, the consumer has to program in a >>certain way AND the provider has to enable sessions. > > > Right. I think we're agreeing: > > - service's scope should be set by the user and the default can be > application > - client (stub instance) by default should, *IF* cookies show up on the > wire, use them. If they don't nothing happens. > > In order to support that behavior, the stub should be default be > configured to copy cookies from responses and send them back on > requests. If the server doesn't send them nothing happens. > > Sanjiva. > >
