API endpoint cannot be accessed by browser

[sxzz]

• Add CORS header

• Cannot visit by browser page, it shows 404 page. It could caused by accept header.

https://jsr.io/@std/assert/meta.json

// 404 page
❯ curl 'https://jsr.io/@std/assert/meta.json' -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7'

// works without accept header
❯ curl 'https://jsr.io/@std/assert/meta.json'

[lucacasonato]

Here what we will do:

• All GET / HEAD requests to the modules bucket (so no Accept: text/html) will get a Access-Control-Allow-Origin: * and Access-Control-Expose-Headers: *
• All HEAD / GET / POST / PUT / PATCH / DELETE requests to the API server (https://api.jsr.io) will get a Access-Control-Allow-Origin: * and Access-Control-Expose-Headers: * header.
• All OPTIONS requests to the API server will return with status 200, and Access-Control-Allow-Headers: Authorization, X-Cloud-Trace-Context, Access-Control-Allow-Methods: HEAD, GET, POST, PUT, PATCH, DELETE, Access-Control-Allow-Origin: *, Access-Control-Max-Age: 3600

[marvinhagemeister]

Wondering if we should move the meta.json endpoint to the api server instead. That way we can avoid the whole accept header stuff which seems to cause most of the confusion.

[lucacasonato]

It's not just the meta.json tho - it's all the module code also.

[takker99]

I was wondering about the current status of this issue. I'd really like to see this bug fixed as I need to call the API from the browser too! If possible, I'm also willing to help with the PR.

Thanks!

[josephrocca]

@lucacasonato I notice that CORS headers are added for fetch(...), but not for import(...) - is this correct behavior? I.e. there is no intention to support importing from the browser?

And if that's true, then I'm wondering whether jsr's position would change on this if Cloudflare provided the bandwidth, as they do with jsdelivr and cdnjs and unpkg and esm.sh? I.e. is it due to bandwidth sustainability concerns?

This would be an awesome point of improvement/differentiation for JSR I think, especially if a mod.ts?js type approach were used for (on-the-fly cached) transpilation to vanilla JS.