<div dir="ltr">Thanks for adding to the conversation Mike.<div><br></div><div>I did some testing and, here is the script I am testing with:<div><br></div><div><div><div><img src="cid:ii_k60xsr9g2" alt="image.png" width="391" height="89"><br></div></div><div><br></div><div><br></div><div><br></div><div>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):</div><div><br></div><div><div><img src="cid:ii_k60y3va83" alt="image.png" style="margin-right: 25px;"><br></div></div><div><br></div><div><br></div><div><br></div><div>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:</div><div><br></div><div><div><img src="cid:ii_k60xs2tb0" alt="image.png" style="margin-right: 25px;"><br></div></div><div><br></div><div>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):</div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="monospace">ACTUAL PERFORMANCE</font></div></div><div><div><font face="monospace">--------------</font></div></div><div><div><font face="monospace">ClientConnected: 10:25:10.973</font></div></div><div><div><font face="monospace">ClientBeginRequest: 10:25:11.158</font></div></div><div><div><font face="monospace">GotRequestHeaders: 10:25:11.158</font></div></div><div><div><font face="monospace">ClientDoneRequest: 10:25:11.158</font></div></div><div><div><font face="monospace">Determine Gateway: 0ms</font></div></div><div><div><font face="monospace">DNS Lookup: 0ms</font></div></div><div><div><font face="monospace">TCP/IP Connect: 0ms</font></div></div><div><div><font face="monospace">HTTPS Handshake: 0ms</font></div></div><div><div><font face="monospace">ServerConnected: 10:25:10.986</font></div></div><div><div><font face="monospace"><span style="background-color:rgb(255,242,204)">FiddlerBeginRequest: 10:25:11.158 <--- Fiddler passing the client's request to the server</span></font></div></div><div><div><font face="monospace">ServerGotRequest: 10:25:11.158</font></div></div><div><div><font face="monospace">ServerBeginResponse: 10:25:21.161</font></div></div><div><div><font face="monospace"><span style="background-color:rgb(255,242,204)">GotResponseHeaders: 10:25:21.162 <--- Fiddler receives HTTP response Headers</span></font></div></div><div><div><font face="monospace"><span style="background-color:rgb(255,242,204)">ServerDoneResponse: 10:25:31.163 <--- Fiddler receives the connection close from server</span></font></div></div><div><div><font face="monospace">ClientBeginResponse: 10:25:31.163</font></div></div><div><div><font face="monospace">ClientDoneResponse: 10:25:31.163</font></div></div><div><div><font face="monospace"><br></font></div></div><div><div><font face="monospace"> Overall Elapsed: 0:00:20.005</font></div></div></blockquote><div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Perhaps Cisco should have included a toggle in the Send HTTP Response step to also close the connection?</div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 29, 2020 at 6:15 PM Norton, Mike <<a href="mailto:mikenorton@pwsd76.ab.ca">mikenorton@pwsd76.ab.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-CA">
<div class="gmail-m_-997971603761458869WordSection1">
<p class="MsoNormal"><span style="color:rgb(31,73,125)">I know nothing about UCCX, but from an HTTP perspective, the problem does not quite make sense as described.<br>
<br>
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.<br>
<br>
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.<br>
<br>
-mn<br>
<br>
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> cisco-voip <<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a>>
<b>On Behalf Of </b>Matthew Loraditch<br>
<b>Sent:</b> January 28, 2020 6:06 AM<br>
<b>To:</b> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<b>Subject:</b> [cisco-voip] HTTP Response for HTTP Triggered Script<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span lang="EN-US">Got the following comment from the developer who is writing an app that will queue a call via http trigger:<u></u><u></u></span></p>
<p class="MsoNormal"><i><span lang="EN-US">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.<u></u><u></u></span></i></p>
<p class="MsoNormal"><i><span lang="EN-US"><u></u> <u></u></span></i></p>
<p class="MsoNormal"><i><span lang="EN-US">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. <u></u><u></u></span></i></p>
<p class="MsoNormal"><i><span lang="EN-US"><u></u> <u></u></span></i></p>
<p class="MsoNormal"><span lang="EN-US">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?<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:12pt;font-family:"Times New Roman",serif"><u></u> <u></u></span></p>
</div>
</div>
</div>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</blockquote></div>