Open peterreisz opened 3 months ago
Hi! Let me look into this. I think we can change it to return the code when no Accept
header is presented at all.
Thanks!
I think it would be great to support corp cache proxies.
But there is another problem: the imports should be rewritten to address the corp proxy not the jsr.
If I import foo
from the corp proxy, it downloads foo
from the corp proxy (which fetch it from jsr) and bar
as dependency, but bar
will be downloaded from jsr not from the corp proxy.
Maybe it can be supported via a header, what do you think?
You can set the JSR_URL
environment variable to your private proxy. All imports from jsr:
will then go to that URL.
Thank you very much! I could not found such option in the docs, I'll try it soon. In the mean while, our nexus team somehow solved the original issue, but we have the enterprise version. So feel free to close it unsolved, in case of you do not want to implement the no accept header logic.
Same problem here. The missing accept
header will trigger the JSR backend to deliver the HTML rendition of the resource instead of the original data.
Thus the Deno CLI will not work properly when JSR_URL is pointing to a Nexus raw proxy.
Hi!
In corp environments there is a central package registry/proxy and everything has to communicate to it. This proxy can be the only one to communicate to the outside world.
I'm trying to setup a raw proxy type repo in Nexus, but it serving me the html content instead of the typescript files.
Nexus can be run easily with docker: https://hub.docker.com/r/sonatype/nexus3/, but here is a curl command, how it tries to fetch the files from Jsr:
The problem is with the accept header. By default the curl send a
*/*
, but the nexus does not send any accept header. The best I can do is append a string at the end of the user-agent header, see above:Deno/1.46.1
Is is possible to fix it in Jsr or is it a Nexus problem?