Reputation: 780
We are using node.js to send SMS to customers, and recently added the status callback to log sent and delivered statuses. We are also now seeing a ton of 11200 errors in our Twilio logs on calls that apparently were successful. Looking at the debugger, I see this in the response body:
Twilio was unable to fetch content from: https://api.mycompany.com:443/api/1.0/sms/response Error: Error reading response: Response does not contain content type
and the message text has:
Msg "Request to StatusCallback URL was unsuccessful." httpResponse "502"
On our side, the handler for /api/1.0/sms/response takes the MessageSid sent with the response, matches it to one in the database, then looks at the MessageStatus. For "sent" it logs the current time in a sent field and saves it back to the database, likewise for delivered. At the end, it just does a res.end() as shown in the node.js example.
Here's the code:
app.post('/api/1.0/sms/response', function(req, res) {
var post_id = req.body.MessageSid || "";
var status = req.body.MessageStatus || "";
var item = Item.create(globals);
if (post_id === "") {
globals.logger.error(moduleName, "POST sms/response", "Missing MessageSid: " + JSON.stringify(req.body), true);
res.end();
return;
}
item.loadFromPostId(post_id).then(function() {
if (status.toLowerCase() === "sent") {
item.sent = new Date();
}
else if (status.toLowerCase() === "delivered") {
item.delivered = new Date();
}
item.save().then(function() {
res.end();
});
});
});
Looking at a couple of the errors, they are when Twilio is trying to send a "delivered" status to us. Checking our database for the MessageSids from these errors, the matching item has a timestamp in the "delivered" column, so it made it all the way through the code to the save.
We also have nothing but 200 responses in our nginx log (which we are using in front of node) for this endpoint, no upstream timeouts and no 502s. So I don't know where this error is coming from, or how to get rid of it.
And yes, we should be handling undelivered, etc., but this was just a quick pass at getting some responses in.
Upvotes: 2
Views: 2920
Reputation: 768
You should respond with HTTP status code 204:
res.status(204).end();
The 204 status is still a success, like 200, but specifically means you are not sending any content back (https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). Note that the following also works, and doesn't need the end():
res.sendStatus(204);
Upvotes: 2
Reputation: 73029
Twilio developer evangelist here.
First up, you have nothing to worry about here. As you say, you are receiving the callbacks and doing what you need to. You probably want to stop the debugger icon flashing at you in your Twilio console though.
From what I can see, this is a small oversight in the case of the Node.js example that you linked to.
Just calling res.end()
closes the stream. It appears that if nothing else has been set, this means the response will get a status code of 200 and no body. While Twilio doesn't expect a response to callbacks like this, it seems it still wants to know something happened.
The error message says that the response didn't have a content type. You can remedy this by setting a content type on the response by calling res.set('Content-Type', 'text/plain')
before you call res.end()
and that seems to please the Twilio HTTP client.
Alternatively, you can use the express response method sendStatus
to set the status and content type of the response in one call. Just call res.sendStatus(200)
and the response will be set to text/plain
, the status will be 200 and there will be a body of "OK". The Twilio HTTP client will happily accept all of that.
I recommend you change your calls to res.end()
to res.sendStatus(200)
and I'm going to go fix that in the Node.js example too.
Upvotes: 2