Silverlight: Caching of negotiate response leads to blizzard of requests #522

Closed
samueldjack opened this Issue Jul 11, 2012 · 1 comment

2 participants

@samueldjack

Just discovered an interesting issue with the Silverlight client. It seems that the browser or the silverlight http stack is caching the response of the /negotiate requests, leading to all clients opened in the browser being allocated the same connectionId.

This causes the clients to continually reconnect to the server, because the connection of a new client with the same connectionId cause previous connections to be ended.

A "quick fix" on the client side is to amend GetNegotiationResponse in HttpBasedTransport so that the first line reads

string negotiateUrl = connection.Url + "negotiate?noCache=" + Guid.NewGuid().GetHashCode();

This ensures each negotiate request has a unique url, so no caching of the response can take place.

A better fix would be to make sure that the server adds the appropriate no-cache headers to the negotiate response.

@davidfowl
SignalR member

We actually changed to use the ClientHttp stack.

@davidfowl davidfowl closed this Jul 23, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment