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
Related
I am linking this file for my media URL:
my goal is for this to be sent as a MMS. I first had a file size error. I fixed that, now I am stuck with this error.
The video will play on my browser. But not on my phone, but it will play on my laptop.
Does anyone have any ideas what I might be doing wrong?
HTTP retrieval failure: Attempt to retrieve media failed. 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
Error Description There was a failure attempting to retrieve the
contents of this URL. An 11200 error is an indicator of a connection
failure between Twilio and your service. When Twilio requests a page
from your server, we wait a maximum of 15 seconds for a response. A
connection failure will occur if no response is returned in that time.
There are many reasons a connection timeout can occur; common causes
are long running database queries or outside processes and calls to
external systems taking a long time to return. It may be possible your
application experienced one of these issues. If you are encountering
this error only intermittently, it is possible that your web server
was temporarily unavailable or experiencing a network outage. 502 Bad
Gateway errors If your debugger is reporting a 502 Bad Gateway error,
this may mean that Twilio's internal server had trouble retrieving
content from your website. Your request must contain a Content-Type
that is valid. Twilio may also have had problems resolving your DNS
name to an IP address, or issues with the network connection. Check
that your web server is started, and is available over the public
Internet.
Request Inspector
+ Expand All
GET https://meetlete.com/media/small-met.mp4 2021-02-21 05:05:07 UTC404 Request URL Parameters Message TextShow Raw
Msg "Attempt to retrieve media failed."
httpResponse "404"
EmailNotification "false"
url "https://meetlete.com/media/small-met.mp4"
LogLevel "ERROR"
Twilio developer evangelist here.
It might be the case that Twilio cached a 404 response to your video at some point. I just tried sending a media message using your URL and it was processed correctly and the video was ingested by Twilio.
I would advise you try again. If you still find that your account has cached the URL response, you could try moving the video to a different address and trying with that instead.
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.
A GET request is constructed to test the network and it is configurable to purposely wait for 15 minutes within the IIS process before responding.
When the request is issued in Chrome without Fiddler it completes successfully.
However, with Fiddler it is usually either 5 or 10 minutes. When replayed from Fiddler it is 5 minutes (only a few trials so not conclusive).
Within the 10 minute cases, inside the Fiddler Statistics tab is
Request was retried after a Receive operation failed
This related SO answer is for POSTS and a prior Fiddler version.
Why do the 504's only occur when Fiddler is running. Is it Fiddler that is issuing the retry logic--does the browser even see the broken/reset connection?
Fiddler Version: v4.6.2.0
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.
I am currently using the free version of heroku. I have a cedar stack and I am sending up HTTP put request every 2 minutes from a client app to my web app. This will work for about the first few(1-6) request but then heroku blocks my incoming request. I've been looking all over the heroku support and I do not see anything about blocking HTTP put request. The only information I've found is that HTTP request have to be under 200 characters. I was wondering if anyone has had a similar problem. If so, how did you allow your web app to receive frequent HTTP request?
Thanks!
Found my problem. I had a bug in my client code which was using up all my sockets.