Improve error messaging for 404s

[analogrelay]

Usually a 404 occurs because sticky sessions are not enabled. We should provide a better error message here.

[ptallett]

Also if the server has a bug and doesn't expose the hub properly, you get an "Error negotiating: error" which makes you think its actually communicated with the server when in fact it hasn't.

I'd think messing up the hub definition on the server is quite common for newbies.

Cheers,
Paul

[analogrelay]

Also if the server has a bug and doesn't expose the hub properly

Can you elaborate on what you mean by "doesn't expose the hub properly"?

[mikaelm12]

I think @ptallett means when you incorrectly configure map hub and the client try to a wrong hub url.
We get an unexpected status code returned from negotiate: 404.

[davidfowl]

There's nothing we can do about that. If you point your client at www.google.com, we don't get a chance to handle it properly. Maybe we could log the mapped hubs at startup and the URL they are bound to. I'm not sure what we could do on the client side besides improve the error message to say we didn't find the negotiate response?

[analogrelay]

I think the ask here is to have an error that actually says we got a 404. At the moment I believe we have a very obscure error. That seems entirely legitimate.

[davidfowl]

I see. This is across all the clients right?

[analogrelay]

The JavaScript client is the one with the worst error messages :). The others are pretty good already.

[analogrelay]

The easiest fix here is to detect the kind of 404 we get. Once a 404 is received:

1. Have the client detect the Connection ID Required error message and throw an error that points to docs on Sticky Sessions. Something like The server does not have a record of the current connection. This usually occurs when you are using multiple server instances and don't have Sticky Sessions enabled. See https://aka.ms/[something] for more information.

2. If the Connection ID Required message is not in the body, it's a more "standard" 404. Throw an error like A SignalR Hub could not be found at '[url]'.. Usually this will be caused by bad routing configuration.

[analogrelay]

We should do this in all the clients. The JS client is the worst because it has no 404 error (it just says "Error"), but the Java and .NET clients could use the detection logic in 1 above.

[analogrelay]

Clarifying further. The work we're doing here is to change all three clients to explicitly detect a 404 response and then throw a specific error (rather than the generic error we throw now) that says something like: "The connection could not be found on the server, either it is not a SignalR endpoint, or the connection may not be present. ... something something try enabling sticky sessions ..."

[analogrelay]

The work for this repo:

• Change error to say "something something 404s. For more detail see https://aka.ms/signalr/404s"
• Log this in the client logs
• Check if aka.ms can be used in code ;)

The work for docs (engineering team to do this) (cc @scottaddie):

• Add a "Troubleshooting" doc with a section on 404s
• Update the aka.ms to point at it.

[analogrelay]

This is cut for 3.0. This can probably meet the bar for 3.1 though.

[jogibaeratvega]

You receive a 404 when your JWT-Token you send in the query param is to large:

Error during WebSocket handshake: Unexpected response code: 404