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.
Related
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.
I know about 200 OK but what is 200 connection established?
To give some background, I am testing out XMLHTTPRequest in an old firefox browser(version 26 to be exact) and I see this as the response code. I am not able to view either the response headers or body so there definitely seems to be some issue. In newer browsers I see 200 OK and there are no issues with the response. I want to understand what this response code means so that I can debug.
In addition I would like to know if this code indicate a problem with the client or server?
Thanks for any help.
The status code is just "200". What follows is the "reason phrase", and it's up to the server to make one up. Note that in HTTP/2 and /3, there is no reason phrase at all.
So; just ignore it.
I am trying to make a POST request to an endpoint served using jetty server. The request errors out saying 413 Request entity too large. But the content-length is only 70KB which I see is way below the default limit of 200KB.
I have tried serving via ngnix server and add client_max_body_size to desired level but that didn't work. I have set the setMaxFormContentSize of WebContext and that didn't help either. I have followed https://wiki.eclipse.org/Jetty/Howto/Configure_Form_Size and that didn't helped me either.
Does anyone have any solution to offer?
wiki.eclipse.org is OLD and is only for Jetty 7 and Jetty 8 (long ago EOL/End of Life). The giant red box at the top of the page that you linked it even tell you this, and gives you a link to the up to date documentation.
If you see a "413 Request entity too large" from Jetty, then it refers the the Request URI and Request Headers.
Note: some 3rd party libraries outside of Jetty's control can also use HttpServletResponse.sendError(413) which would result in the same response status message as you reported.
Judging by your screenshot, which does not include all of the details, (it's really better to copy/paste the text when making questions on stackoverflow, screenshots often hide details that are critical in getting a direct answer), your Cookie header is massive and is causing the 413 error by pushing the Request Headers over 8k in size.
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.