Loading ...
Sorry, an error occurred while loading the content.

Re: [soapbuilders] Fw: SOAPBuilders Sessions

Expand Messages
  • Simon Fell
    ... The session token can be arbitrary XML, is it expected that the client will preserve things like comments & PIs ?, It will also need to preserve all the in
    Message 1 of 3 , Jun 8, 2002
    • 0 Attachment
      On Thu, 6 Jun 2002 00:30:47 -0700, in soap you wrote:

      >Hi y'all!
      >
      >Here's James' first cut at spec'ing a very simple sessions-over-SOAP-headers implementation which we came up with at the soapbuilders F2F this week. I've got this working (client + server) in Axis, and I hear tell that there will be versions from certain other companies in the near term. This is NOT meant to provide anything more than simple correlation of a message to a client-session (like a SOAP header cookie), and it is intentionally kept very simple. If toolkits agree to implement this, however, we would gain the ability to do transport-independent server-managed sessions interoperably! IMHO, this is super cool.
      >
      >If we all like this, I would suggest the next steps are probably to a) implement first versions, b) get the spec cleaned up and inline with the SOAP 1.2 Module rules, and c) submit it to the W3C as a note?
      >
      >Thoughts, comments?
      >
      >--Glen

      The session token can be arbitrary XML, is it expected that the client
      will preserve things like comments & PIs ?, It will also need to
      preserve all the in scope namespace prefix's from the source message,
      as you can't tell where there might be QNames in attribute or element
      content within the session token.

      The actor handling doesn't seem to handle all the cases, if there's a
      message path of

      Client A -> Intermediary B -> Server C
      Then there are potentially 3 different sessions
      between A & B
      between A & C
      between B & C

      whilst actor and sessionActor solve some of these, there's a problem
      that if there's active sessions between A & C and B & C for a given
      message, there's no way for C to distinguish which Session header is
      from which source.

      Personally, I think we should start by codifying current practice
      [session token is always a string, no attempt to do anything special
      for intermediaries]

      Cheers
      Simon
      www.pocketsoap.com
    Your message has been successfully submitted and would be delivered to recipients shortly.