[cisco-voip] HTTP Response for HTTP Triggered Script

[Anthony Holloway]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/7c1cef6a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 51058 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/7c1cef6a/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6747 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/7c1cef6a/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 29256 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/7c1cef6a/attachment-0002.png>