const { createProxyMiddleware } = require('http-proxy-middleware');
const { env } = require('process');
const target = env.ASPNETCORE_HTTPS_PORT ? `https://localhost:${env.ASPNETCORE_HTTPS_PORT}` :
env.ASPNETCORE_URLS ? env.ASPNETCORE_URLS.split(';')[0] : 'http://localhost:[IIS-HTTP-PORT]';
const context = [
"/weatherforecast",
module.exports = function(app) {
const appProxy = createProxyMiddleware(context, {
target: target,
secure: false,
headers: {
Connection: 'Keep-Alive'
});
app.use(appProxy);
In addition it looks like POSTing to the website that relies on the SPA files will now break?
aspnet/Announcements#495
I'd love to ask this on the issue but you keep locking issues and strangling collaboration in order to maintain this course. We're getting further and further away from last-known-good!
@richstokoe here is how you can do it.
Please advise how to workaround some of the limitations of the http-proxy-middleware. For example, in multiple path matching, you cannot use string paths and wildcard paths together. This is not backwards-compatible with the SpaServices approach.
You have full control of how requests are matched, for example:
const pathFilter = function (path, req) {
return path.match('^/api') && req.method === 'GET';
const apiProxy = createProxyMiddleware({
target: 'http://www.example.org',
pathFilter: pathFilter,
});aspnet/Announcements#495
I'd love to ask this on the issue but you keep locking issues and strangling collaboration in order to maintain this course. We're getting further and further away from last-known-good!
Our announcements repo is locked as it is just the central place for folks to get updates. It is ok to file an issue in the repo explicitly.
In addition it looks like POSTing to the website that relies on the SPA files will now break?
aspnet/Announcements#495
Could you give us a concrete example on how this impacts you?
Not being able to POST to a website? OAuth2 Auth Code flow. POSTing data across micro-frontend modules. I may be misunderstanding the effect of this change in which case please correct me.
That's not what this change does. The change only prevents the fallback route to be matched on POST requests. The fallback route only matches when no other route matches and returns the default document (index.html).
@javiercn Thanks for the reply.
Based on what you've documented above is this fallback not the mechanism by which SPA pages are loaded? (i.e. index.html in the public folder for the CRA client app)
Does this mean that we can't POST to an ASPNet 7 SPA?
Does this mean that we can't POST to an ASPNet 7 SPA?
No, it does not mean that. It means the following:
If you did not have a route for "/Something/else" defined on the server, the application will serve "index.html" (your SPA). In previous versions it would serve the default document independent of the verb used. That caused problems because the middleware/fallback (it does not matter whether it was the old or the new approach) would handle requests that were meant for the server instead of returning a 404.
The change that we did, constrains when index.html is returned when the route does not match to avoid sending the default document back when the verb is not GET or HEAD.
Maybe this table helps
Before:
Method Server / Route defined
