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.
Related
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.
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
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.
A few weeks ago we started noticing strange errors from the google client API or google drive JS api (not sure which, the URL reference is below), they have increased in frequency over the last few days
TypeError: Cannot read property 'sl' of undefined
This seems to be affecting windows Chrome mostly - a typical example of the user agent from our error logs is
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31)
from what I could see, the only line with .sl is this:
if(!this.b.headers.Authorization){var f=(0,_.Hx)(_.p,_.p);f&&f[_.Ak.pl.sl]&&(c=f[_.Ak.pl.sl].split(/\w+/))}
this comes from
https://apis.google.com/_/scs/apps-static/_/js/k=oz.gapi.en.uSTvEdNXb7o.O/m=client/rt=j/sv=1/d=1/ed=1/am=UQ/rs=AItRSTOm1KS5pZVEepZkn9qQJeuQZC_Qjw/cb=gapi.loaded_0
I know this is intentionally cryptic, so it's beyond me to suggest how to fix it, but I would appreciate if someone looks into this as the frequency seems to be increasing. Perhaps a guard around _Ak.pl to check if it's not null before executing .sl ?
I managed to resolve the problem which was reported. The issue is due to the authorize settings. Some settings seems to be not working for the app. Now the app works with following settings:
gapi.auth.authorize({client_id: clientId, scope: scopes, immediate: false}, handleAuthResult);
Previously the app was configured to run offline.
Note: In the code, clientId and scopes are variables, handleAuthResult is an associated function.
I'm reeealy stuck and way over my head.
I've got a e-commerce site set up with woocommerce and realex (the merchant company).
I'm having problems with the response URL, it is being denied when programmatic (non user-agent) requests are being made.
try:
$ wget curl http://fifty2printsolutions.com/?wc-api=WC_Gateway_Realex_Redirect
But when you set a valid user agent:
try:
$ curl -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30" http://fifty2printsolutions.com/?wc-api=WC_Gateway_Realex_Redirect
it works.
This points to a server configuration issue, it seems like programmatic (non user-agent) requests are being denied by his server with a 406 response.
At least this is what the extension author has told me
How can I got about fixing this? I'm with host papa, the support is a bit lack luster.
Any help would be greatly appreciated.
I think you might be dealing with an Apache mod_security issue here. From my experimentation, as long as I have something in the User-Agent, it will process ok. However, if I include the words libwww or perl in the User-Agent, or leave it blank, it doesn't work.
Realex Epage Redirect uses "epage.cgi / libwww-perl" (or similar, I don't have it in front of me) as the User-Agent. This hits both of those rules, so it is getting blocked. We've come across this before and the only solution is to ask the administrators of the site to modify the mod_security rules to allow this. We once changed the User-Agent string to something else, but incredibly, several shopping carts suddenly stopped working and we had to roll the change out.
Hope this helps
Owen