In my application, the browser http requests are queued.
On http request to server, the client should be notified by server that the request is been accepted (say with http status as 202 or just a message "In Progress"), so that client side queue can send the second request to server.
Once the first request executes completely, the client should be again notified by server saying the request is success (say http status as 200).
Using promises didn't help as two times rendering was not possible; one with actual request-response and the other when the thread completes the work.
Though I know one request and multiple response are not possible. But is there a way to render the text at least twice for a request?
One solution is to do it as multi step process.
So, suppose we are using Rabbit MQ as our messaging queue. Let's follow steps below:
Queue sent out a request to server that process some resource.
Server accepted the request and started processing it and sent out a return message with code 202 / in process. Also, it did send a message to rabbit mq to process the request meanwhile sending out the message code to client.
The other message got consumed and process completed and pushed the message 200 to say success queue with some identification number to identify the request from client e.g. customer id, urn no. etc. Or rather than pushing just put a message status in database and use another call from client to check if the message status is updated to the expected one.
Client can now easily check the status of it's request by checking up the queue or database.
You may use ajax requests as well to track if some process is completed or not as server side.
Hope it helps.
Related
I am not sure the title of the posting truly describes my issue but here is what's happening, in more details. I have an ASP.Net MVC application that redirects to a page hosted in an external system. This external hosted page is used to enter the details of a credit card in order to process a payment. Once the payment is processed, the hosted payment page is sending an HTTP POST to a webhook URL which was provided by me, when the transfer to the HPP was made. I have a Web API controller in my ASP.Net MVC application and this will be used to receive the webhook call. Now, to test it while I am running everything locally, I had to use ngrok to create a private tunnel between the HPP and my local Web API endpoint.
I have a breakpoint in my Web API controller and I am getting the data sent by the HPP, data that contains details about the approved payment. The controller responds with an HTTP 200 which I see it in the ngrok console:
For some reasons, this HTTP 200 is not propagated back to the HPP which should display a back button to yield control back to my web application where we all started in the first place. Instead, the browser is directed to an URL which is the exact URL for the webhook, the one that was provided when the transfer to the HPP is made:
Any idea why this is happening? Is the ngrok not returning the HTTP 200 back to the caller, which is the hosted payment page?
Any suggestions would be greatly appreciated.
TIA,
Eddie
Turns out that this is not an issue with ngrok. The remote Hosted Payment Page (HPP) is not sending an HTTP POST to a RESTful endpoint, as I erroneously assumed. Insted it is returning to a specified URL and sends the response as hidden fields.
So if anyone is ever facing the same situation, please make sure you understand exactly the behaviour of the remote server. This could send the response as an HTTP POST sent to a specified URL or could yield the control back to your application by means of navigation where the response is send as hidden fields (HTTP POST with content of type "application/x-www-form-urlencoded").
I've been running into some issues with the twilio and bot framework channel integration.
In a nutshell, a large number of incoming messages and conversations that happen through the twilio channel time out and the user never receives a response. Then, after a few minutes, all the piled up responses will arrive at the same time - almost as iff the responder hangs and then continues. The error occurs only with the twilio channel - the bot it working perfectly when embedded in site, when tested in azure portal, and when connected to slack.
When I first connected twilio to the bot, it was running completely fine for a few days, and now I am getting the following error on roughly 70-80% of the messages which occur through that channel.
On a high level, the error I'm getting specific to the channel is: 'There was an error sending this message to your bot: HTTP status code GatewayTimeout'
Inside of the app logs, the error recording is far more detailed, but still provides no insight into what specifically is causing the error:
HTTP Error 500.1013 - Internal Server Error
The page cannot be displayed because an internal server error has occurred.
Most likely causes:
•IIS received the request; however, an internal error occurred during the processing of the request. The root cause of this error depends on which module handles the request and what was happening in the worker process when this error occurred.
•IIS was not able to access the web.config file for the Web site or application. This can occur if the NTFS permissions are set incorrectly.
•IIS was not able to process configuration for the Web site or application.
•The authenticated user does not have permission to use this DLL.
•The request is mapped to a managed handler but the .NET Extensibility Feature is not installed.
Things you can try:
•Ensure that the NTFS permissions for the web.config file are correct and allow access to the Web server's machine account.
•Check the event logs to see if any additional information was logged.
•Verify the permissions for the DLL.
•Install the .NET Extensibility feature if the request is mapped to a managed handler.
•Create a tracing rule to track failed requests for this HTTP status code. For more information about creating a tracing rule for failed requests, click here.
On the twilio side, I get the following error
Error - 11200
HTTP retrieval failure
Possible Causes
Web server returned a 4xx or 5xx HTTP response to Twilio
Misconfigured Web Server
Network disruptions between Twilio and your web server
No Content-Type header attached to response
Content-Type doesn't match actual content, e.g. an MP3 file that is being served with Content-Type: audio/x-wav, instead of Content-Type: audio/mpeg
Possible Solutions
Double check that your TwiML URL does not return a 4xx or 5xx error
Make certain that the URL does not perform a 302 redirect to an invalid URL
Confirm the URL requested is not protected by HTTP Auth
Make sure your web server allows HTTP POST requests to static resources (if the URL refers to .xml or .html files)
Verify your web server is up and responsive
Check to see that the URL host is not a private or local IP address
Verify the ping times and packet loss between your web server and www.twilio.com
Twilio sends a request to Bot Framework, and gets the following info back
Msg "Bad Gateway"
sourceComponent "14100"
ErrorCode "11200"
EmailNotification "false"
httpResponse "502"
LogLevel "ERROR"
url "https://sms.botframework.com/api/sms"
Twilio was unable to fetch content from: http://sms.botframework.com/api/sms
Error: Total timeout is triggered. Configured tt is 15000ms and we attempted 1 time(s)
Account SID: redacted
SID: redacted
Request ID: redacted
Remote Host: sms.botframework.com
Request Method: POST
Request URI: http://sms.botframework.com/api/sms
URL Fragment: true
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Some additional information:
Bot is working perfectly when embedded in website, when tested in the azure portal, and when connected to slack.
Error seems to occur at the locations in code where await context.sendActivity(messageToReturnToUser) or await dialogContext.beginDialog(this.id) or basically anywhere where we send something back to the user.
After a few minutes, bot framework will send all the piled up messages to the end user and they'll get a chunk of sms messages back to back.
Error cannot be replicated in any other channel or in the bot framework emulator.
Error does not occur with every message. An arbitrary number of messages will go through fine and get responses immediately, but then an arbitrary number of messages will be subject to the delays.
I am using paid twilio numbers, no trial errors happening here!
Has anyone else had this problem? Any input or help would be appreciated!
This issue has been mitigated on the Azure/BotFramework side. If you are still having issues, please let me know.
From the docs at https://developer.surveymonkey.net/api/v3/#webhooks and trying out the feature I understand that webhooks first do a HEAD and then POST call to my webhook receiver public API.
Does the webhook POST callback to my receiver API require a response from it??
Many webhooks pay attention to responses and re-send requests if the application errors out. Just wanted to understand how SurveyMonkey deals with responses.
Perhaps this should be specified in the documentation, but no, SurveyMonkey doesn't expect a response, as in it doesn't expect any particular body returned to us.
That said it does expect you to return a 2xx HTTP status code (which is usually automatically handled by any web server framework you use).
I am running a ruby on rails app with unicorn server on Heroku.
Scenario: Client sends a HTTP POST request with a large request body.
My understanding:
Heroku router establishes a HTTP connection with client and forwards it to the dyno
30 sec counter starts
Dyno starts reading the request body from client through the connection
if client is slow and takes greater than 30 secs to transfer the request body Heroku issues a HTTP 503 error and closes the connection
Is my understanding right? Or is it the case that Heroku only starts the timeout counter after the dyno has read the request body?
According to Heroku's docs:
HTTP requests have an initial 30 second window in which the web
process must return response data (either the completed response or
some amount of response data to indicate that the process is active).
Processes that do not send response data within the initial 30-second
window will see an H12 error in their logs.
I think it's designed to prevent dynos being tied up for any particular length of time
My understanding is the timer starts as soon as you send a request to the server. Once the request is routed, the timer begins to count down until you start getting data back
I am creating outbound SMS communication and need to set a cookie so I can track the conversation thread. I'm using the Twilio-charp client and did not see a way to set a cookie or and http header. Is this possible or do I need to pursue a different route?
Edit:
I need to elucidate here. In my scenario I need to set a cookie with a transaction id that needs to included in the originating outbound message. For example I will be creating an SMS message that will request a response from the user: "Text (1) to approve, (2) to decline".
The Twilio sample code details a page that receives a message, checks for a cookie, then creates one if it does not already exist. In my scenario I need the cookie to be in the outbound message.
I contacted support at Twilio and they stated that cookies can not be sent with their REST API. Cookies can be exchanged from the response endpoint that you create where you set the http header.
This means that you must wait for the user to reply to your first message before you can insert cookies to the http headers.
You can definitely set a cookie to track the conversation thread. Details and sample code can be found here under Twilio's .NET (C#) quickstarts: http://www.twilio.com/docs/quickstart/csharp/sms/tracking-conversations