Hi Dojo
I’ve seen HTTP protocols where multiple connections are defined inside a session. For example, when you want to adjust an XML file but you need to login first in order to be able to make modifications.
The connections are listed in such order:
- Connection 1: login request/response
- Connection 2: update modified XML request/response
- Connection 3: logout request/response
When the login succeeds, the login response contains a cookie which should be used in the remaining requests defined in the session. As you can see in the snippet down below, no Cookie headers were added in the Update request or in the Logout request.
This approach works fine when executing the session once. So I would assume that such cookies are accepted in the background and automatically carried on to the remaining requets of the session without the need of defining Cookie headers. Is that correct?
If so, is this the reason why you would opt to use multiple connections inside one session instead of using a separate session for each connection? Please if you could provide me some information about this or share a link to the documentation, that would be great!
The session is defined like this:
Thank you in advance!
Kind regards
Hi Michiel,
Without defining all the details, the same connection handle for the http session is used for all Connections defined in your Session. The connection handle is only closed (if there are no errors/timeouts) when all Connections in the Session have been executed.
DataMiner uses WinHTTP for all http communication defined in protocols. Some articles with a bit more details information:
Do note there are also additional articles that will be posted in the future with more details, but I hope this already answers some of your questions.
From your question, I assumed you were mainly looking for more details on the inner workings. Do I understand correctly that this approach only works the first time? What error do you then get the second time?
Hi Joey
Yes, when executing this session twice with a minute in between, only the first execution would succeed. The second one would fail. After some investigation, we could see that no Cookie headers were used in the update request and the logout request of the second execution. At the time the element was created on a DMA which is running the Windows Server 2008 R2 Standard operating system. When recreating the element on a DMA which is running the Windows Server 2012 R2 Standard operating system, all executions would succeed. We assume that the root cause is a bug in the winhttp.dll that is used by Windows Server 2008 R2 Standard.
Hi Joey
Thank you very much for your reply! Indeed, as expected, the 2nd article defines the following: “WinHTTP obtains the cookie from the servers Set-Cookie header and stores it in a cache on a per-session basis. This cookie is resent on subsequent requests in the same WinHTTP session where the target matches the source of the cookie.”
However, we would also expect the same behaviour when you would execute the session twice with approximately a minute in between right?