Chandler Newman

@AndreasTruetschel Any progress?

Thanks. I assume you're just creating a "BrowserHttpMessageHandler"/"BlazorHttpMessageHandler" or something of the sorts that will be used regardless of whether it's server side of client side blazor?

Would it also be possible for the ```RazorComponents``` naming to be replaced with ```ServerSideBlazor``` as they have switched back to the old naming?

> > I assume you're just creating a "BrowserHttpMessageHandler"/"BlazorHttpMessageHandler" or something of the sorts that will be used regardless of whether it's server side of client side blazor? > >...

Maybe a slight change of course is a better option. Currently ```HttpClient``` etc is only needed for the inbuilt c# transports, i.e. ```ServerSentEventsTransport```, whereas the JS proxied versions like ```BlazorServerSentEventsTransport```...

It feels like a lot of baggage having a custom ```HttpMessageHandler``` if it is only used for the negotiation. Instead having just a JS implemented negotiater might simply things.

> > The browser console is playing tango in the client-side and server-side case. I have to take a deeper look on this. > > I don't think this is...

Which version of ```BlazorSignalR``` are you using? ```MessagePack``` support has never been explicitly tested, however ```JSON``` and ```MessagePack``` use the same marshalling code. If you could provide a minimal reproduction...

Thanks for that. I think I have an idea of what's happening, but I won't get a chance to take a look until later. My assumption is that when the...

#24 Tracks supporting binary protocols. Once that has been fixed, then we can look into this issue.