I have some rest and GraphQL services works with ruby and typescript (with nestjs framework).
I've noticed that a couple of days ago some of the POST requests failed due to params validation error.
After further investagaion, it seems like on some requests the body params sphoradicly drops from the requests somewhere on the network. It happen for small amount of requests (less than 1%).
This issue started when no changes deployed on the server or clients side. My clients are iOS and android apps and it happens for both platforms.
I've tried to find the exact point on the network that the body dropped, with no success.I've also tried to find a solutions to similar issue on the net.
Does anyone have any idea what can it be? I haven'e found any relevant information about similar issues.
Thanks!
I've spent the day searching for a way to restrict the google cloud storage json API to only accept calls from our server ip (note, I am using the java client).
I found a really old post that seemed to indicate that it was possible. https://groups.google.com/forum/m/#!searchin/gs-discussion/Whitelist$20/gs-discussion/nTwMuygttbA
But things seem to have changed since then.
I tried looking in the quota section in the console but can't find anything there either.
Is this possible? Where can it be configured?
I'm trying to figure out how to use the recommended approach from Microsoft and use the Installation Model to handle registrations.
I want to be able to get some information about the installations that should have been saved and I see that there are two methods that could be useful
GetInstallation(string installationId) and GetInstallationAsync(string installationId)
Problem is that when making at call to any of them I never get a response back. I can't figure out what I might be doing wrong.
Here's the answer from a similar question (that still holds true as of Nov 2016):
... there's no way to get all installations for a hub. In the future, the
product team is planning to add this feature to the installations
model, but it will work in a different way. Instead of making it a
runtime operation, you'll provide your storage [account] connection string and
you'll get a blob with everything associated with the hub.
Situation
We're using socket.io for mobile-server communications. Since we can't force-upgrade users' devices, if we want to upgrade to version 1 (non-back-compatible), we have to handle both versions on the server for a while.
Question
What are the options?
My current favourite is to wrap both the old version and the new version in a multiplexer. It detects the version of the incoming request based on headers and query parameters and thereby knows which functions to invoke.
Another (shittier) option is to wrap the new version in a module that can translate the old version of the protocol into the new version (and back again) when necessary. This suffers from a serious drawback. It would be time-consuming and uncertain work to ensure I've properly determined and handled all the tiny differences. Some differences might take some serious massaging.
(In case you're curious or it's helpful to know, we're doing this in Go.)
It appears that you could run two separate versions of socket.io on the server. Since the two versions don't have unique module filenames you would probably need to load one version from a different path. And, then obviously when loading the modules and initializing them you'd assign them to differently named variables. For example:
var io_old = require('old/socket.io');
var io = require('socket.io);
Once you have the two versions loaded on the server, I think there are two different approaches for how they could be run.
1) Use a different port for each version. The older version would use the default port 80 (no configuration change required for that) which is shared with the node.js web server. The newer version would be run on a different port (say port 3000). You would then initialize each version of socket.io to its own port. Your newer version clients would then connect to the the port the newer version was running on.
For the old socket.io server running on port 80, you would use whatever initialization you already have which probably hooks into your existing http server.
For the new socket.io server running on some other port, you would initialize it separately like this:
var io_old = require('old/socket.io')(server);
var io = require('socket.io')(3000);
Then, in the new version client, you would specify port 3000 when connecting.
var socket = io("http://yourdomain.com:3000");
2) Use a different HTTP request path for each version. By default, each socket.io connection starts with an HTTP request that looks like this: http://yourdomain.com/socket.io?EIO=xx&transport=xxx?t=xxx. But, the /socket.io portion of that request is configurable and two separate versions of socket.io could each be using a different path name. On the server, the .listen() method that starts socket.io listening takes an optional options object which can be configured with a custom path as in path: "/socket.io-v2". And similarly, the .connect() method in the client also accepts that options object. It's kind of hard to find the documentation for this option because it's actually an engine.io option (which socket.io uses), but socket.io passes the options through to engine.io.
I have not tried either of these myself, but I've studied how socket.io connections are initiated from client and server and it looks like the underlying engine supports this capability and I can see no reason why it should not work.
Here's how you'd change the path on the server:
var io = require('socket.io')(server, {path: "/socket.io.v1"});
Then, in the client code for the new version, you'd connect like this:
var socket = io({path: "/socket.io.v1"});
This would then result in the initial connection request being made to an HTTP URL like this:
http://yourdomain.com/socket.io.v1?EIO=xx&transport=xxx?t=xxx
Which would be handled by a different request handler on your HTTP server, thus separating the two version.
FYI, it is also possible that the EIO=3 query parameter in the socket.io connection URL is actually an engine.io version number and that can also be used to discern client version and "do the right thing" based on that value. I have not found any documentation on how that works and could not even find where that query parameter was looked at in the engine.io or socket.io source code so that would take more investigation as a another possibility.
I don't really have an immediate solution for this, but I have some kind of advice. I guess you could use it to save a lot of time.
first of all Im working in a startup which uses socketIo for almost
everything
We knew that this problem would happen so our initial design was to
make everything pluggable which means that we can swap out socketio for
sockjs and it will still work.
The way its done is by defining the common set of APIs which rarely change
in a system. We call it managers. The managers can just expose the API which the rest of the devs need to use without messing up anything. It speeds up a lot.
The manager implementation changes in the background but still the APIs are the same, so the engineers working on the core can confidently make changes.
Seems like you have a tight dependency in your code. Or may be not. I'm not so sure. Try following this principle if you haven't.
We're going to go the route of keeping both the 0.9.x version and the current version as separate libraries on the server. Eventually, when the pool of clients has more-or-less all updated, we'll just pull the plug on the 0.9.x version.
The way we'll manage the two versions is by wrapping the socket.io services in a package that will determine which wrapped socket.io version to pass the request off to. This determination will depend on features of the request, such as custom headers (that can be added to the newer clients) as well as query parameters and other headers utilized exclusively by one version or the other.
Since we're using Go, there's so far no universally agreed upon way to manage dependencies, let alone a way that can respect version differences. Assuming the back-compat branch of the repo wasn't broken (which it is), we'd have two options. The first would be to fork the repo and make the back-compat version the master. We'd then import it as if it had nothing to do with the other one. The second option would be to use gopkg.in to pretend the separate branches were separate repos.
In either event, we could import the two branches/repos like so
import (
socketioV0 "github.com/path/to/older/version"
socketioV1 "github.com/path/to/current/version"
)
And then refer to them in the code using their import names socketioV0 and socketioV1.
My team and I are working against a few webservices that require SOAP Message Headers to be available when making a request. We are not in control of these webservices so we can't change the implementation, even if we wanted to (or at least not without a lot of pain). We just need to be able to have authentication related information & a couple of other items passed through our message headers.
I've read of a few people who've had this problem in the past with no clear indication on if they succeeded in pulling it off on Monotouch.
Here's what I've read: http://forums.monotouch.net/yaf_postsm2104.aspx so far.
Any ideas on what we can do to overcome this on the Monotouch framework?
Here's what i'm trying to do for now:
using (var scope = new OperationContextScope (client.InnerChannel))
{
client.GetHistories += handler;
OperationContext.Current.OutgoingMessageHeaders.Add (MessageHeader.CreateHeader ("EnvironmentInfo", "http://schemas.contoso.com",
ServiceContext.Current.OperatingEnvironment));
OperationContext.Current.OutgoingMessageHeaders.Add (MessageHeader.CreateHeader ("AuthenticationToken", "http://schemas.contoso.com",
ServiceContext.Current.Token));
client.GetHistoriesAsync (ServiceContext.Current.OperatingEnvironment, ServiceContext.Current.Token, request);
}
Thanks for your time.
JM
I was not able to get Message Headers to work with WCF in Mono 2.6. I tried several different ways (including how you do it in your example) - it just doesn't work in Mono 2.6.
I raised a bug for this, which I then closed after discovering it is fixed in the latest trunk. So if you run against Mono 2.7 or greater, this should work.