Lots of H17 Heroku Errors - ruby

I am working on a ruby project using sinatra, heroku, activerecord, and postgresql. I am consistantly getting this error:
2015-06-10T19:30:52.015492+00:00 heroku[router]: http_error="Invalid HTTP status line" at=error code=H17 desc="Poorly formatted HTTP response" method=POST path="/login" host=myapp.herokuapp.com request_id=e5c29131-1c22-47d7-84a4-b1b51e4a3905 fwd="74.71.233.85" dyno=web.1 connect=1ms service=135ms status=503 bytes=862
I cannot find out how to fix it. If anyone needs any more information to fix it, I would be happy to provide it.

I solved my problem by just making some other irrelevant edits and pushing to heroku again which caused a dyno restart which is what I believe solved the problem. Now it works just fine. If anyone can come up with an explanation for this that would be much appreciated.
And if it could be added as an answer it would be accepted! I find this very weird.

In my case this was happening with a POST request to which my dyno was not returning a response code. It was fixed by returning a valid response code, such as 200. For example:
post '/user/:user_id/favourites/:item_id' do
[add the favourite, and if successful...]
200
end

Related

How can I fix error H31 at Heroku/PointDNS?

I use PointDNS to manage my DNS. In July, they had a migration from IPv4 to IPv6, but I did everything they recommended for the migration.
Heroku also had an update, but I checked everything mentioned on this email (I didn't get the email myself), and everything seems to be the way it's supposed to be. Any idea on what might be the issue?
I have no idea if I configured something wrong if Heroku is having issues (this doesn't seem related), or if PointDNS is having issues (says the last downtime was 4 hours ago)
2021-08-13T21:48:45.365853+00:00 heroku[router]: at=error code=H31 desc="Misdirected Request" method=GET path="/favicon.ico" host=site.com.br request_id=2bcf003e-1c07-4fd7-a549-5a7488699c8d fwd="179.24.194.180" dyno= connect= service= status=421 bytes= protocol=https agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36"
It may sound kind of weird but, my app was working in some instances while not working on others.
I simply just renamed the application, thinking that changing the DNS might help with the problem and to my surprise, it did!
I'm trying to get into the root cause of this, and would update the answer once I have something concrete. Till the time being, try renaming your application and it may help.
P.S. I know this question is old, but still posting an answer in case anyone else is looking for a way out.

Heroku routing of HTTP PATCH requests

I am having trouble sending HTTP PATCH requests to my application. Here is the log I see:
Mar 22 20:34:40 canvs heroku/router: at=info method=METHOD_OTHER path="/v2/art/edit/132/" host=canvs.herokuapp.com request_id=9f4eafe5-5624-45fb-b7d2 fwd="010.173.106.34" dyno=web.1 connect=0ms service=109ms status=405 bytes=185
Somehow the PATCH verb seems to be replaced by METHOD_OTHER.
This has suddenly started happening so I am pretty confident that its not something I have changed.
Also btw, the same request works with a HTTPS connection.
PATCH is not (yet) a HTTP standard (but rather a proposed standard), and seems to not be as widely supported as other HTTP methods/verbs.
For example, I have experienced that some versions of Squid (maybe even the latest, haven't tested) replace PATCH with METHOD_OTHER.
You could try switching to PUT, which seems to be more widely supported.

casperjs and https still not working

Ok guys, we've been working on this for a while now(many days). I have seen and tried all the documentation on the "casperjs --ignore-ssl-errors=yes test4.js". We have tried every scenario on the net regarding the https issue but nothing is working. Tests are working on our local host but when we run the test on the https servers we are getting an about:blank null return on te https status. Again casperjs --ignore-ssl-errors=yes test4.js and all other combinations are not fixing the problem. Are we overlooking something? Thanks
You may also need --ssl-protocol=any in arguments.

Heroku: Force Error Backtrace To Display In Development Mode

I am running a sinatra application on Heroku, and I'm seeing the generic error page:
Stuff I've Tried So Far
heroku logs returns a generic "H10 - Application Crashed" error, which doesn't tell me what the actual cause is.
I've used heroku config vars to set RACK_ENV=development and verified that it is set that way using heroku config. I thought this would force a backtrace to be displayed on the screen but it does not.
Questions
How can I force a backtrace to be displayed in dev mode?
What else can I do to track down the source of this error?
I got a response from Heroku support about this.
Everything I did was correct, the problem is the application boot errors won't display to the screen, and this was a boot error. The source of the error was further back in the backtrace in heroku logs, so that was in fact the right place to look in this case, I just missed it.
Setting RACK_ENV=development is the correct way to display application runtime errors to the screen, according to support.

Timeout Request at redirecting on Heroku

I run into request timeout on a page that emit simple queries to database on Heroku using Flask, only on the first access of that page after a period of inactivity. I have looked into similar questions asked, but i don't think they fits my case.
To clarify and give the context to this problem further:
Only after refreshing, accessing that page does not cause request timeout.
However, the problem only reappears after a long pause of inactivity on the website.
I traced the error with printing statement in the code. The timeout seems to be when at the end of one page redirecting to another. All the code runs properly, including the query to the database, until it hits return redirect.
For example, the actual error is on the path specified as this new page redirected.
at=error code=H12 desc="Request timeout" method=GET path=/resultSearch host=nutrientdata.herokuapp.com fwd="216.165.95.73" dyno=web.1 connect=1ms service=30001ms status=503 bytes=0
To support the point that the code inside is not the problem: I traced database performance on new relic, but the query emitted on this page takes very short amount of time.
I tried replicating the situation on local host but it does not give me any error. However, indeed, redirecting to the page first time on local host takes longer time than the subsequent redirecting to the same page (only after a period of inactivity)
I tried pinging the app using new relic - however i'm not pinging that particular page, but the first page of the app.
I tried to fix this by, instead of redirecting to another page, just rendering one (temporary) page before allowing other redirecting. It turns out that the problem now is shifted to new page. In other words, request timeout is now on another redirecting. All of these, again, happen during the first access to the app after a period of inactivity.
I think what I'm looking for is why does redirecting for the first time after a long period of inactivity takes longer than another. And how should i fix it to solve this request timeout.
Any help on this would be much appreciated. Thank you!
You said the problem is present even in your local devserver so it's not Heroku related.
Normally this type of problems are due to database's transparent caching.
Trace, in your local devserver, the queries you're making to the db in the slowest scenario (that is that new page you're accessing after the redirect).
Probably there's an index to make/improve.

Resources