[cisco-voip] HTTP Response for HTTP Triggered Script

Thu Jan 30 13:37:40 EST 2020

Very interesting, thanks to both of you for the knowledge drop. Of course I’ve already rewritten everything at this point, but good to know for the future!

Matthew Loraditch
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com | e: MLoraditch at heliontechnologies.com
From: Anthony Holloway <avholloway+cisco-voip at gmail.com>
Sent: Thursday, January 30, 2020 1:35 PM
To: Norton, Mike <mikenorton at pwsd76.ab.ca>
Cc: Matthew Loraditch <MLoraditch at heliontechnologies.com>; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] HTTP Response for HTTP Triggered Script

[EXTERNAL]

All good info Mike, and thank you for the conversation!

The Content-Length header is in fact missing from the server response.

Interestingly, when I add a content length header, the browser/client now "completes" the transaction at the first 10 second delay.

[cid:image001.png at 01D5D772.6FB564A0]

[cid:image002.png at 01D5D772.6FB564A0]

[cid:image003.png at 01D5D772.6FB564A0]

So, we now have a working solution for Matt, where he doesn't need the Trigger Application step.  Rather, he simply needs to set the Content-Length header.  Sorry!  ;)

On Thu, Jan 30, 2020 at 11:46 AM Norton, Mike <mikenorton at pwsd76.ab.ca<mailto:mikenorton at pwsd76.ab.ca>> wrote:
An HTTP conversation ending is not necessarily the same thing as the TCP connection closing. Often they are, but that is not a safe assumption. If you are waiting for the TCP connection to close, then really you’re waiting for the wrong thing. You can tell the HTTP conversation is done when as many bytes of content have come in as was specified in the content-length header. Either party could close the TCP connection at that point, if it wants.

Firefox would know that, of course. So it sounds like maybe the server does not send a content-length header, or is indeed sending the initial bit of content then waiting.

If you can do the request with HTTP 1.0, it might be worth seeing if that gives different server behaviour. Otherwise I guess it is workarounds on the Cisco side or a custom HTTP client implementation.

-mn
From: Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway%2Bcisco-voip at gmail.com>>
Sent: January 30, 2020 10:01 AM
To: Norton, Mike <mikenorton at pwsd76.ab.ca<mailto:mikenorton at pwsd76.ab.ca>>
Cc: Matthew Loraditch <MLoraditch at heliontechnologies.com<mailto:MLoraditch at heliontechnologies.com>>; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] HTTP Response for HTTP Triggered Script

Thanks for adding to the conversation Mike.

I did some testing and, here is the script I am testing with:

[image.png]

If I open up the dev tools in FF, the browser is spinning the whole 20sec, and there is no status code next to the request. (not a very exciting screenshot):

[image.png]

But then once the 20 seconds expire and the script ends, the browser fully loads the page and now shows the 200 status code, plus some timing details:

[image.png]

If I get timings out of Fiddler, it looks like this (where we can see the 10 second gaps between sending the request, server starts to respond, server finishes response):

ACTUAL PERFORMANCE
--------------
ClientConnected: 10:25:10.973
ClientBeginRequest: 10:25:11.158
GotRequestHeaders: 10:25:11.158
ClientDoneRequest: 10:25:11.158
Determine Gateway: 0ms
DNS Lookup: 0ms
TCP/IP Connect: 0ms
HTTPS Handshake: 0ms
ServerConnected: 10:25:10.986
FiddlerBeginRequest: 10:25:11.158 <--- Fiddler passing the client's request to the server
ServerGotRequest: 10:25:11.158
ServerBeginResponse: 10:25:21.161
GotResponseHeaders: 10:25:21.162 <--- Fiddler receives HTTP response Headers
ServerDoneResponse: 10:25:31.163 <--- Fiddler receives the connection close from server
ClientBeginResponse: 10:25:31.163
ClientDoneResponse: 10:25:31.163

Overall Elapsed: 0:00:20.005

And if I use Postman to try and set the Connection header to close, the server does not honor it (and from my research, it does not have to), and so it still takes 20 seconds to close the connection.  Interestingly, in Postman, I can see the response Headers after 10 seconds, but it does not render a body until after 20 seconds.  So the Send HTTP Response is actually sending headers and body content, but the client is not rendering any body content until the request is complete.  Contrast that with FF, which shows no header/status code until the full 20 seconds expires.  Each client is coded a little different I guess.

I did do some testing with wireshark, but either my skills in it are too limited to show anything of more value than what I already knew, or the app simply wont show anything new and exciting beyond what I already gathered.

In short, it would seem as though the server is in ultimate control of closing the connection, and I just don't see how we can affect that, other than executing the End step.

Perhaps Cisco should have included a toggle in the Send HTTP Response step to also close the connection?

On Wed, Jan 29, 2020 at 6:15 PM Norton, Mike <mikenorton at pwsd76.ab.ca<mailto:mikenorton at pwsd76.ab.ca>> wrote:
I know nothing about UCCX, but from an HTTP perspective, the problem does not quite make sense as described.

If the HTTP server is “spitting back some HTML” then it had to have also spit back a status code. The status code is in the HTTP response headers before the content. Content cannot possibly have come without a status code.

Perhaps your developer is waiting for the TCP session to close (which is not the same thing as an HTTP response ending), but neglected to request that HTTP keep-alive not be used? In HTTP 1.1, keep-alive is the default. If the server supports keep-alive but the requestor does not want it, then the request needs to have “Connection: close” in the headers.

-mn

From: cisco-voip <cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>> On Behalf Of Matthew Loraditch
Sent: January 28, 2020 6:06 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] HTTP Response for HTTP Triggered Script

Got the following comment from the developer who is writing an app that will queue a call via http trigger:
It seems like the MobileApp integration is accepting my request, spits back some HTML, but the HTTP request remains open until the queued call is answered.

Ideally, that HTTP request would be closed with a successful HTTP status code (e.g. HTTP 200) when the call was queued, so that I can report back to the user that they can wait for a callback.

I understand his problem, but I see no way  of fixing it. The send http response command doesn’t seem to have any settings but the doc sent back. Is this normal behavior or can I do something with the doc being sent back to make it work?

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/bfadf236/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 9422 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/bfadf236/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 18056 bytes
Desc: image002.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/bfadf236/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 44818 bytes
Desc: image003.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/bfadf236/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 6747 bytes
Desc: image004.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/bfadf236/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 29256 bytes
Desc: image005.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/bfadf236/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 51058 bytes
Desc: image006.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/bfadf236/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image899906.png
Type: image/png
Size: 9409 bytes
Desc: image899906.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/bfadf236/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image167736.png
Type: image/png
Size: 431 bytes
Desc: image167736.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/bfadf236/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image103791.png
Type: image/png
Size: 561 bytes
Desc: image103791.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/bfadf236/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image347681.png
Type: image/png
Size: 444 bytes
Desc: image347681.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/bfadf236/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image942972.jpg
Type: image/jpeg
Size: 19523 bytes
Desc: image942972.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/bfadf236/attachment.jpg>