[cisco-voip] HTTP Response for HTTP Triggered Script

[Norton, Mike]

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200130/6b7bd793/attachment.htm>