How to solve the cross-domain issue

[ying2025]

What is your suggestion?

How to solve the cross-domain issue? Place the workbench.web.main.css file in the CDN and import it in workbench.html through http://xxx.cdn.com, but there will be a (blocked:csp) issue

Why do you want this feature?

Are there any workarounds to get this functionality today?

Are you interested in submitting a PR for this?

[code-asher]

I believe you would need to edit the CSP tag in workbench.html to include your CDN.

[code-asher]

Ah wait actually the CSP is set via a header from webClientServer.ts.

[ying2025]

I believe you would need to edit the CSP tag in workbench.html to include your CDN.

yes, is there some example for this ? In fact, I haven't found the file code-server/code-server/lib/vscode/src/vs/server/node/webClientServer.ts

[ying2025]

@code-asher Otherwise, I try to upload all files under code-server/lib/vscode/out/vs to the CDN, so that files such as workbench.web.main.css, workbench.web.main.js, and workbench.web.main.nls.js can be directly accessed from the CDN. However, the loading speed is actually slower, and it seems like a lot of content is being downloaded. It download some extensions/theme-defaults/themes and others @code-asher

[code-asher]

Likely the most robust option would be to introduce a new flag, --cdn or something like that and it could comprehensively make sure all assets are loaded from a CDN.

I think it will be tricky to edit the CSP after the fact because it will be bundled together and minified with all the other code. But if you want to try, check out code-server/lib/vscode/out/server-main.js and look for Content-Security-Policy.

Another idea is that if you have code-server behind a reverse proxy, you can change the headers it sends back to add your CDN to the CSP header.

[ying2025]

Likely the most robust option would be to introduce a new flag, --cdn or something like that and it could comprehensively make sure all assets are loaded from a CDN.

I think it will be tricky to edit the CSP after the fact because it will be bundled together and minified with all the other code. But if you want to try, check out code-server/lib/vscode/out/server-main.js and look for Content-Security-Policy.

Another idea is that if you have code-server behind a reverse proxy, you can change the headers it sends back to add your CDN to the CSP header.

I have added a go proxy, which forwards the resource code-server/lib/vscode/out/vs to the CDN. However, the front-end request processing for workbench.web.main.js has become slower. Additionally, requests for vscode-remote-resource?path= are also slow. I also plan to forward these requests to the CDN. What impact will this have?

In addition, for front-end access, how can compression be enabled on the server side, such as

[code-asher]

The vscode-remote-resource requests might be tricky because they can request any file on the server, so if a user installs for example a new theme, it will try to get these resources and they probably will not exist on your CDN.

As for compression, requests from code-server should already be compressed; we use Express's compression middleware. Are you not seeing them be compressed? Mine shows compression using brotli.

If you mean enabling compression on your CDN though, maybe you will have to enable it there.

Or possibly your reverse proxy is removing the compression?

[ying2025]

The vscode-remote-resource requests might be tricky because they can request any file on the server, so if a user installs for example a new theme, it will try to get these resources and they probably will not exist on your CDN.

As for compression, requests from code-server should already be compressed; we use Express's compression middleware. Are you not seeing them be compressed? Mine shows compression using brotli.

If you mean enabling compression on your CDN though, maybe you will have to enable it there.

Or possibly your reverse proxy is removing the compression?

I have written a reverse proxy. For requests to vscode-remote-resource, if they are on the CDN, they will be requested from the CDN. If they cannot be requested from the CDN, they will be forwarded to VSCode.

I haven't noticed any compression. Is it caused by my proxy service, or is the bytes returned already compressed?

[ying2025]

Additionally, I would like to implement a policy of not forwarding verification for non-core requests. Is there a list of these requests?

[code-asher]

My guess is they are caused by the proxy service. Could you access code-server directly to confirm?

I do not believe there is a list of non-core requests anywhere. By non-core do you mean requests made to external services? Only the extension gallery comes to mind (https://open-vsx.org by default).

Ah and there is a request to https://github.com (to check for version updates).

[ying2025]

My guess is they are caused by the proxy service. Could you access code-server directly to confirm?

I do not believe there is a list of non-core requests anywhere. By non-core do you mean requests made to external services? Only the extension gallery comes to mind (https://open-vsx.org by default).

Ah and there is a request to https://github.com (to check for version updates).

Okay, I'll give it a try. What impact will requesting access to the module caches under /static/out and /static/node_modules/ have?

- vscode/stable-0b84523121d6302fbe30eda7899ec3b81810748e/static/out/*
- vscode/stable-0b84523121d6302fbe30eda7899ec3b81810748e/static/node_modules/*

[code-asher]

Those are static resources so should be no issue in mirroring them via CDN.

[ying2025]

Those are static resources so should be no issue in mirroring them via CDN.

Why is the loading speed of the static/out/vs/workbench/workbench.web.main.js file slower when hosted on a content delivery network (CDN)? When not hosted on a CDN, the loading time is around 1 second, but when hosted on a CDN, the loading time increases to 3-4 seconds, other file is normal.

[code-asher]

That might be a question better asked to your CDN provider. It could be any number of reasons, but ultimately it sounds like your connection to wherever code-server is hosted is faster than your connection to the CDN. What sort of speeds do you see when you ping both?

The main workbench file is by far the largest of all the assets, so any discrepancy in download speed will be particularly noticeable with it.

[ying2025]

That might be a question better asked to your CDN provider. It could be any number of reasons, but ultimately it sounds like your connection to wherever code-server is hosted is faster than your connection to the CDN. What sort of speeds do you see when you ping both?

The main workbench file is by far the largest of all the assets, so any discrepancy in download speed will be particularly noticeable with it.

The main workbench file on the CDN primarily spends time on content download, with a service return time of approximately 270ms; pinging the CDN takes longer, with icmp_seq=1 ttl=51 time=13.3 ms, while pinging the codeserver takes approximately icmp_seq=4 ttl=52 time=4.78 ms.

[code-asher]

Interesting, yeah seems like your connection to the CDN is slower.