Reports

Angular redirects all routes to app-routing (older version. Newer standalone version has another way to define routes). To access the backend, and especially if you're using the same URL, you need to proxy it to the backend. By default, QuickApp only proxy the common /api (and some others like /swagger and /connect for authentication, etc. But if you add to Program.cs app.MapHub<MyHub>('/hub'), that's not going to be redirected to the backend. To redirect, you need to make change to proxy.conf.js. See below:

const { env } = require('process');

const target = env.ASPNETCORE_HTTPS_PORT ? `https://localhost:${env.ASPNETCORE_HTTPS_PORT}` :
  env.ASPNETCORE_URLS ? env.ASPNETCORE_URLS.split(';')[0] : 'https://localhost:7085';

const PROXY_CONFIG = [
  {
    context: [
      "/api",
      "/swagger",
      "/connect",
      "/oauth",
      "/.well-known"
    ],
    target,
    secure: false
  }, 
  {  // ADD THIS
    context: ["/hub"],
    target,
    secure: false,
    ws: true,  // Because SignalR uses WebSocket NOT HTTPS, you need to specify this. 
    changeOrigin: true,  // To match your 'target', one assumes... That's what AI told me. 
    logLevel: "debug"  // If you need debugging. 
  }
]

module.exports = PROXY_CONFIG;

That'll solve the 400 issue not found.

But after that, why do one get 405 Method Not Found? At first, one thought it is really the need for POST, but however one tried, one couldn't get it to work. In the end, one realized that in one's use-signalr.service.ts where one call the SignalR, before, one changes what it calls. Before one knows about changing proxy, to make it run, one changes the url from /hub to /api/hub so it'll pass through; and that's the problem. Changing it back solve the problem. Though, one didn't dig deeper into researching whether it's because

/api is using https and not ws that causes the problem (as per defined in proxy.conf.js), or
The URL simply doesn't exist in the backend, since one already changed it everywhere except for the service.ts, so it returns that error. This sounds kinda weird -- shouldn't it have returned 400 instead? But no, it returned 405, which is kinda confusing.

And it not only magically solve the problem, but it also solve the ALLOW GET, HEAD issue. Even when it don't allow POST, when one set skipNegotiation: true instead of false in the frontend, it worked like a charm! One'll let you investigate on the 'why' if you'd like to know. One'll stay with the 'how' here.

79664526