I’ve recently developed a simple Ktor app and organized a hosting for it on Apache Webserver + Tomcat.
The app has post { … } route used for processing HTTP POST requests. The route works fine for all requests except the first one.
Some additional tracing shows that request processing stucks on the line
call.receiveText()
where I read the POST JSON body for further parsing. The request is stuck until network timeout, and I couldn’t detect the actual processing time (it takes minutes).
Every following POST request with exactly the same content is processed fine. In Tomcat settings I put “load-on-startup” - it didn’t affect the result.
What could be the reason of such behavior? I assume some lazy loading issue. Does Ktor provide some mechanism to force initialization of the library components?
Related
I am developing a stack based on NodeJS + Express + SocketIO and I deployed it to Heroku.
The stack involves using concurrency in dyno (I followed Heroku's guide on how to do it) and a Redis adapter for SocketIO.
In addition to SocketIO, a SPA is served with express.static(), responsing to a dynamic path (/app/:name) and API to a path (/api/) and everything works fine, even on Heroku.
The problem arises when this webapp (or just an HTTP client like the one in WebStorm) makes a POST request to the /api/:app/login endpoint and exactly at the point of the express.json middleware which, locally works fine, while on Heroku it randomly takes more than 30 seconds without giving any error on the server and the Heroku router returns H12 error in the logs and returns error 503 to my client.
I noticed it doesn't happen always but almost 3/4 of the times and after i refresh the page or retry the request many times, it works.
Any advice on what could be blocking the middleware?
Thanks
I tried placing logs middleware all over to find the middleware causing the timeout
I have two cloud services up and running.
frontend (URL: https://frontend-abc-ez.a.run.app/)
backend (URL: http://backend-abc-ez.a.run.app/)
Frontend is calling the backend through a nuxt.js server middleware proxy to dodge the CORS problematics.
The call is coming through - I can see that in the backend log files. However the response is not really coming back through because of CORS. I see this error in the console:
Mixed Content: The page at 'https://frontend-abc-ez.a.run.app/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://backend-abc-ez.a.run.app/login'. This request has been blocked; the content must be served over HTTPS.
What I find weird is that I configured the backend url with https but it is enforced as http - at least that is what the error is telling me. Also I see a /login path segment in the unsecure URL. Why is that? I never explicitly defined that endpoint. Is it the security layer proxy of the run service itself?
Anyway - I need to get through this properly and am having a hard time to understand the source of the problem.
For some reason as I rechecked the applications today in the morning everything went fine. I have really no idea why it is working now. I did not change a thing - I waited for the answers here before I'd continue.
Very weird. But the solution so far seems to be waiting. Maybe Cloud Run had some troubles.
How can I monitor http requests that were made by node in node-webkit? When I make a request I don't see it in the developer tools. I can see the request only when I make it with jquery or xmlhttprequest.
I've binded a console.log on the 'end' event and I can see that node-webkit is actually doing the request and it's returning me a correct response. But doing this blind requests is very hard because there is absolutely no way to debug them (except for logging the params that I've called the request method with).
Such low-level procedures can only be handled by the supported node.js so one of these node.js functions is bound to solve your HTTP header monitoring problem:
https://nodejs.org/dist/latest-v6.x/docs/api/http.html#http_event_checkexpectation
We attempted a passbook program but it never made it out of beta, but there are a few passes out there that keep phoning home (and throwing errors because the passes are out of sync with existing data). My plan is to 404 any incoming requests, but I'm not sure if that is the best way to handle existing passes. Any other ideas or is 404 the right solution?
There are a few of options:
Return an updated pass without that has a blank web service url
Return an appropriate error
Remove the DNS entry of the subdomain
Update the web service url
Any of the fields in the pass can be updated including the web service url. Removing the url will prevent further requests for updates. This s potentially the most effective, but would require a bit of development to return the updated pass and would need to be maintained until all passes have been "disabled."
Return an appropriate error code
It may be easier to simply return an error code. This could be done through the web server configuration preventing the requests from being processed by your application (and presumably stop the errors in the application). This would allow you to remove the code altogether from your application.
The Passbook Web Service Reference indicates that Passbook will eventually give up when receiving persistent errors.
If a request fails—for example, due to a network connectivity issue—Passbook tries again several times after waiting a period of time. Each time it tries again, it waits longer. If the request continues to fail, it eventually gives up.
The documentation also indicates that standard HTTP status codes should be used in the response from the call to Getting the Latest Version of a Pass (and others).
Response
If request is authorized, return HTTP status 200 with a payload of the pass data.
If the request is not authorized, return HTTP status 401.
Otherwise, return the appropriate standard HTTP status.
Discussion
Support standard HTTP caching on this endpoint: check for the If-Modified-Since header and return HTTP status code 304 if the pass has not changed.
It sounds like the ending of the passbook program is permanent in which case 410 Gone would be an appropriate error code. (From RFC 2616).
410 Gone
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.
The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.
Remove subdomain DNS
If your web service url was set up on a separate subdomain (e.g. passbook.example.com) you can simply remove the DNS entry for the subdomain. The requests will never reach the server and Passbook will eventually give up.
I'm investigating a problem a user is having with a web application that is built using Yii.
The user is not seeing the Yii 'flash' session-based user-feedback messages. These messages are shown once to a user and then destroyed (so they're not shown on subsequent page loads).
I took a look at the server access logs and I noticed something weird.
When this user requests a page there is a second identical request but from a different IP and with a different User Agent string. The second request is often at the same time or is sometimes (at most) a couple of minutes later. A bit of googling leads me to the conclusion that the user is browsing the web using a HTTP Proxy.
So, is this likely to be a HTTP Proxy? Or could it be something more suspicious? And if it is a HTTP Proxy, does this explain why they're not seeing the flash session messages? Could it be that the messages are being 'shown' to the Proxy and then destroyed?