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 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 *On Behalf Of *Matthew > Loraditch > *Sent:* January 28, 2020 6:06 AM > *To:* cisco-voip@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@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] HTTP Response for HTTP Triggered Script
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 On Behalf Of Matthew Loraditch Sent: January 28, 2020 6:06 AM To: cisco-voip@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] HTTP Response for HTTP Triggered Script
I mean, you could probably contain it all in a single app script and by inspecting the triggering events/data, figure out which phase you're on. E.g., If trigger is HTTP Trigger then Phase 1; If Trigger is JTAPI extension 1000, then Phase 3, else Phase 2 There's probably something to be concerned about when it comes to packing so much into such a small space, and troubleshooting issues might be harder, but I bet its achievable. On Tue, Jan 28, 2020 at 9:40 AM Matthew Loraditch < mloradi...@heliontechnologies.com> wrote: > So basically I need 3 separate applications. The HTTP Trigger to take the > input then pass the input to another application that then places the call > into the queue that’s in a third application. > > > > Matthew Loraditch > Sr. Network Engineer > p: *443.541.1518* <443.541.1518> > w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/> | > e: *mloradi...@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 > *Sent:* Tuesday, January 28, 2020 10:24 AM > *To:* Johnson, Tim > *Cc:* Matthew Loraditch ; Cisco VoIP > Group > *Subject:* Re: [cisco-voip] HTTP Response for HTTP Triggered Script > > > > [EXTERNAL] > > > > Tim is correct: this is normal from my experience too. > > > > I feel partly responsible for your woes, since I think you found that > solution from me pointing out the script repository online. > > > > Thinking about it some more, I think I would have the HTTP Triggered > Application use the Trigger Application step in async mode, to start the > initial callback feature, and then it can just End almost immediately. > > > > I through together this quick and dirty MS Paint representation of it: > > > > > > There's like a dozen ways to solve this, and this is just one of them. > Some details are left out of the drawing on purpose, so if you get stuck, > let's keep this thread going. > > > > > > On Tue, Jan 28, 2020, 7:14 AM Johnson, Tim wrote: > > As far as my experience, this is “normal” for UCCX. Yes, I believe the > request stays open until the script ends. I believe we opened up a TAC case > about it a year or two ago but I don’t believe it went anywhere. > > > > *From:* cisco-voip *On Behalf Of *Matthew > Loraditch > *Sent:* Tuesday, January 28, 2020 8:06 AM > *To:* cisco-voip@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? > > > > > > *Matthew Loraditch*** > > *Sr. Network Engineer* > > p: *443.541.1518* <443.541.1518> > > w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/> > > | > > e: *mloradi...@heliontechnologies.com* > > <http://www.heliontechnologies.com/> > > <http://www.heliontechnologies.com/> > > <http://www.heliontechnologies.com/> > > <http://www.heliontechnologies.com/> > > <http://www.heliontechnologies.com/> > > <http://www.heliontechnologies.com/> > > ___ > cisco-voip mailing list > *cisco-voip@puck.nether.net* > *https://puck.nether.net/mailman/listinfo/cisco-voip* > <http://www.heliontechnologies.com/> > > ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] HTTP Response for HTTP Triggered Script
Bingo bango bongo. From: Matthew Loraditch Sent: Tuesday, January 28, 2020 10:40 AM To: Anthony Holloway ; Johnson, Tim Cc: Cisco VoIP Group Subject: RE: [cisco-voip] HTTP Response for HTTP Triggered Script So basically I need 3 separate applications. The HTTP Trigger to take the input then pass the input to another application that then places the call into the queue that’s in a third application. Matthew Loraditch Sr. Network Engineer p: 443.541.1518 w: www.heliontechnologies.com<http://www.heliontechnologies.com/> | e: mloradi...@heliontechnologies.com<mailto:mloradi...@heliontechnologies.com> [Helion Technologies]<http://www.heliontechnologies.com/> [Facebook]<https://facebook.com/heliontech> [Twitter]<https://twitter.com/heliontech> [LinkedIn]<https://www.linkedin.com/company/helion-technologies> [cid:image006.jpg@01D5D5C7.81067570] From: Anthony Holloway mailto:avholloway+cisco-v...@gmail.com>> Sent: Tuesday, January 28, 2020 10:24 AM To: Johnson, Tim mailto:johns...@cmich.edu>> Cc: Matthew Loraditch mailto:mloradi...@heliontechnologies.com>>; Cisco VoIP Group mailto:cisco-voip@puck.nether.net>> Subject: Re: [cisco-voip] HTTP Response for HTTP Triggered Script [EXTERNAL] Tim is correct: this is normal from my experience too. I feel partly responsible for your woes, since I think you found that solution from me pointing out the script repository online. Thinking about it some more, I think I would have the HTTP Triggered Application use the Trigger Application step in async mode, to start the initial callback feature, and then it can just End almost immediately. I through together this quick and dirty MS Paint representation of it: [cid:image007.png@01D5D5C7.81067570] There's like a dozen ways to solve this, and this is just one of them. Some details are left out of the drawing on purpose, so if you get stuck, let's keep this thread going. On Tue, Jan 28, 2020, 7:14 AM Johnson, Tim mailto:johns...@cmich.edu>> wrote: As far as my experience, this is “normal” for UCCX. Yes, I believe the request stays open until the script ends. I believe we opened up a TAC case about it a year or two ago but I don’t believe it went anywhere. From: cisco-voip mailto:cisco-voip-boun...@puck.nether.net>> On Behalf Of Matthew Loraditch Sent: Tuesday, January 28, 2020 8:06 AM To: cisco-voip@puck.nether.net<mailto:cisco-voip@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? Matthew Loraditch Sr. Network Engineer p: 443.541.1518 w: www.heliontechnologies.com<http://www.heliontechnologies.com/> | e: mloradi...@heliontechnologies.com<mailto:mloradi...@heliontechnologies.com> <http://www.heliontechnologies.com/> ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip<http://www.heliontechnologies.com/> ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] HTTP Response for HTTP Triggered Script
This is normal and expected behavior. Use the HTTP trigger app to catch the request, use Trigger Application step, and sessions to pass success failure, then end the http trigged app. That'll do the request. Good luck On Tue, Jan 28, 2020 at 6:15 AM Johnson, Tim wrote: > As far as my experience, this is “normal” for UCCX. Yes, I believe the > request stays open until the script ends. I believe we opened up a TAC case > about it a year or two ago but I don’t believe it went anywhere. > > > > *From:* cisco-voip *On Behalf Of *Matthew > Loraditch > *Sent:* Tuesday, January 28, 2020 8:06 AM > *To:* cisco-voip@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? > > > > > > *Matthew Loraditch*** > > *Sr. Network Engineer* > > p: *443.541.1518* <443.541.1518> > > w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/> > > | > > e: *mloradi...@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> > > > ___ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] HTTP Response for HTTP Triggered Script
Tim is correct: this is normal from my experience too. I feel partly responsible for your woes, since I think you found that solution from me pointing out the script repository online. Thinking about it some more, I think I would have the HTTP Triggered Application use the Trigger Application step in async mode, to start the initial callback feature, and then it can just End almost immediately. I through together this quick and dirty MS Paint representation of it: [image: image.png] There's like a dozen ways to solve this, and this is just one of them. Some details are left out of the drawing on purpose, so if you get stuck, let's keep this thread going. On Tue, Jan 28, 2020, 7:14 AM Johnson, Tim wrote: > As far as my experience, this is “normal” for UCCX. Yes, I believe the > request stays open until the script ends. I believe we opened up a TAC case > about it a year or two ago but I don’t believe it went anywhere. > > > > *From:* cisco-voip *On Behalf Of *Matthew > Loraditch > *Sent:* Tuesday, January 28, 2020 8:06 AM > *To:* cisco-voip@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? > > > > > > *Matthew Loraditch*** > > *Sr. Network Engineer* > > p: *443.541.1518* <443.541.1518> > > w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/> > > | > > e: *mloradi...@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> > > > ___ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] HTTP Response for HTTP Triggered Script
As far as my experience, this is “normal” for UCCX. Yes, I believe the request stays open until the script ends. I believe we opened up a TAC case about it a year or two ago but I don’t believe it went anywhere. From: cisco-voip On Behalf Of Matthew Loraditch Sent: Tuesday, January 28, 2020 8:06 AM To: cisco-voip@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? Matthew Loraditch Sr. Network Engineer p: 443.541.1518 w: www.heliontechnologies.com<http://www.heliontechnologies.com/> | e: mloradi...@heliontechnologies.com<mailto:mloradi...@heliontechnologies.com> [Helion Technologies]<http://www.heliontechnologies.com/> [Facebook]<https://facebook.com/heliontech> [Twitter]<https://twitter.com/heliontech> [LinkedIn]<https://www.linkedin.com/company/helion-technologies> [cid:image006.jpg@01D5D5B2.75C99DA0] ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
[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? Matthew Loraditch Sr. Network Engineer p: 443.541.1518 w: www.heliontechnologies.com | e: mloradi...@heliontechnologies.com ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
