Is this a cross-domain issue? And the science of my forwarding processing scheme? Will there be a pit? Why do people taunt this proposal?

The thing is this:
1. The same server, PHP website is 80 port, C # WebService is 81 port.
2. Client, use Ajax to get data from WebService. Ajax is a PHP web site, with 80 ports.
3. Using Chrome debugging, Error "' Access-control-allow-origin '", checked, said to be a cross-domain problem.

Question 1: Is this a cross-domain issue?

4. Searching the internet for half a day, most of the solutions are very complex and need to change the WebService code.
I think: if because of cross-domain problem, changed the WebService code, not when I do not cross the domain, the code will have to change all back?
This is obviously unscientific.

5. I feel that the cross-domain problem in my case, due to the webservcei port, is inconsistent with the PHP Web port, causing the URL to be visited changed, causing cross-domain problems. So, the solution is also very simple, with the TCP tool, do a forwarding is not OK?

6. Since PHP is using Apache, I have directly configured the forwarding in Apache, that is, reverse proxy, the 80 port forwarding to 81,ajax successfully obtained to WebService data, problem resolution.

7. Here's my question:
With simple configuration forwarding, you can easily take care of this and do not need to modify the WebService code. So, why do I put this thing in QQ group to say again, a lot of people say taunt?

Reply content:

The thing is this:
1. The same server, PHP website is 80 port, C # WebService is 81 port.
2. Client, use Ajax to get data from WebService. Ajax is a PHP web site, with 80 ports.
3. Using Chrome debugging, Error "' Access-control-allow-origin '", checked, said to be a cross-domain problem.

Question 1: Is this a cross-domain issue?

4. Searching the internet for half a day, most of the solutions are very complex and need to change the WebService code.
I think: if because of cross-domain problem, changed the WebService code, not when I do not cross the domain, the code will have to change all back?
This is obviously unscientific.

5. I feel that the cross-domain problem in my case, due to the webservcei port, is inconsistent with the PHP Web port, causing the URL to be visited changed, causing cross-domain problems. So, the solution is also very simple, with the TCP tool, do a forwarding is not OK?

6. Since PHP is using Apache, I have directly configured the forwarding in Apache, that is, reverse proxy, the 80 port forwarding to 81,ajax successfully obtained to WebService data, problem resolution.

7. Here's my question:
With simple configuration forwarding, you can easily take care of this and do not need to modify the WebService code. So, why do I put this thing in QQ group to say again, a lot of people say taunt?

The browser's same-origin policy requires the protocol, domain name, and port to be exactly the same, so this is a cross-domain issue

To solve cross-domain problems, server-side forwarding is one of the solutions, and there is no need to change the other end of the code, like cors or JSONP need the other end of the support

As for a lot of people who say taunt ... I can't answer that.

Do not know why taunt ...

My elasticsearch because to give more people to use, I again on the server on the Nginx anti-generation added Pam authentication.

The scheme is fine, but if the sub-site is more likely to be more cumbersome to configure, and modify the server configuration is not as easy as modifying the js,php.
Recommended JSONP

Perhaps mocking is the architecture of standalone windows,c++++ and PHP?

Also recommended JSONP processing, simple rude, if the SVR return code cannot be modified and then consider the reverse proxy

