[cisco-voip] HTTP Response for HTTP Triggered Script

Fri Jan 31 12:37:01 EST 2020

Good info guys, nice work

On Thu, Jan 30, 2020 at 11:38 AM Matthew Loraditch <
MLoraditch at heliontechnologies.com> wrote:

> 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* <443.541.1518>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
> e: *MLoraditch at heliontechnologies.com* <MLoraditch at heliontechnologies.com>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
> [image: Facebook] <https://facebook.com/heliontech>
> [image: Twitter] <https://twitter.com/heliontech>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *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.
>
>
>
>
>
>
>
>
>
>
>
> 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>
> 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>
> *Sent:* January 30, 2020 10:01 AM
> *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
>
>
>
> Thanks for adding to the conversation Mike.
>
>
>
> I did some testing and, here is the script I am testing with:
>
>
>
> [image: 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: 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: 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>
> 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> *On Behalf Of *Matthew
> Loraditch
> *Sent:* January 28, 2020 6:06 AM
> *To:* 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
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> 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/20200131/7f722357/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 9422 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200131/7f722357/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 18056 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200131/7f722357/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 44818 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200131/7f722357/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 6747 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200131/7f722357/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 29256 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200131/7f722357/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 51058 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200131/7f722357/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image899906.png
Type: image/png
Size: 9409 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200131/7f722357/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image167736.png
Type: image/png
Size: 431 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200131/7f722357/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image103791.png
Type: image/png
Size: 561 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200131/7f722357/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image347681.png
Type: image/png
Size: 444 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200131/7f722357/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image942972.jpg
Type: image/jpeg
Size: 19523 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200131/7f722357/attachment.jpg>