You might be wondering what happens next after we successfully log on to our web service. How does the load balancer know that we are authorized to make other calls, when other calls do not require a username and password to be sent along with other parameters?
Some web services send back a special token, which is generated on the server and is associated with the account that is using the API. If that was the case, we would have to incorporate this token with every request that we send to the web service.
Things are much simpler with the Netscaler load balancer. After we send our login request, and if our authentication details are correct, the load balancer will respond with a simple "OK" message. It will also respond with a special cookie in the HTTP header, which acts as our token. Instead of incorporating token details into every SOAP request, we simply need to make sure that we have this cookie set in our HTTP header when we're sending subsequent requests to our web service. Listing 219 shows the output from the tcpdump command, which clearly demonstrates this in action (I have omitted other TCP packets and removed irrelevant binary data, so only HTTP and SOAP protocols are shown).
Listing 2-19. HTTP encapsulated SOAP login request and login response messages
11:11:35.283170 IP 192.168.1.10.40494 > 192.168.1.1.http: P 1:166(165) ack 1 win 5488 [... ]
POST /soap/ HTTP/1.1 Host: 192.168.1.1 Accept-Encoding: identity Content-Length: 540 Content-Type: text/xml; charset=utf-8 SOAPAction: "urn:NSConfigAction" [... ]
<SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:^
"http://www.w3.org/2001/XMLSchema-instance" SOAP-ENV:encodingStyle=^ "http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Header></SOAP-ENV:-' Header><SOAP-ENV:Body xmlns:ns1="urn:NSConfig"><ns1:login><username>nstest</username>^ <password>nstest</password></ns1:login></SOAP-ENV:Body></SOAP-ENV:Envelope>
11:11:35.567226 IP 192.168.1.1.http > 192.168.1.10.40494: P 1:949(948) ack 706 win 57620 [... ]
HTTP/1.1 200 OK
Date: Mon, 29 Jun 2009 11:13:08 GMT Server: Apache
Last-Modified: Mon, 29 Jun 2009 11:13:08 GMT Status: 200 OK Content-Length: 622 Connection: closeSet-Cookie:^
192.168.1.1; Path=/soapContent-Type: text/xml; charset=utf-8
<?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV=^
"urn:NSConfig"><SOAP-ENV:Header></SOAP-ENV:Header><SOAP-ENV:Body SOAP-ENV:-encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" id=^ "_0"><ns:loginResponse><return xsi:type=^
"ns:simpleResult"><rc xsi:type="xsd:unsignedInt">0</rc><message xsi:type=^ "xsd:string">Done</message></return></ns:loginResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>
We can see that with our initial request for login action we send a SOAP message with our credentials encapsulated as HTTP POST request.
The response is also a SOAP message, encapsulated into an HTTP response. The SOAP response does not carry much useful information; it contains only two pieces of data: a numeric return code (rc) and an alphanumeric string (message). When everything is OK, rc is set to 0 and message is set to Done.
The HTTP header carries more important information—it sets a cookie that we need to use with other requests:
Was this article helpful?