Use jbrowse.org link for the alias files to fix CORS errors

[cmdcolin]

Currently, every time I load up the app I get a CORS error for this file

This is the whole screenshot I see almost every app load

Access to fetch at 'https://s3.amazonaws.com/jbrowse.org/genomes/hg19/hg19_aliases.txt' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
rangeFetcher.ts:13 GET https://s3.amazonaws.com/jbrowse.org/genomes/hg19/hg19_aliases.txt net::ERR_FAILED
getfetch @ rangeFetcher.ts:13

It has been hypothesized that this is due to weird amazon throttling, because it is intermittent and doesn't affect all users

Ian also ran into this for a VCF file once, which makes it somewhat concerning that it would affect other users

This change would specifically help me, because the cloudfront'ed file has no issue, hence this tiny change.

It is some question of whether this should be done to more of our files. I don't know the details or implications of making cloudfront host giant files that we range request against (could be expensive)

[codecov]

Codecov Report

Merging #1511 (fed7a25) into master (628a349) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1511   +/-   ##
=======================================
  Coverage   59.47%   59.47%           
=======================================
  Files         435      435           
  Lines       19511    19511           
  Branches     4552     4552           
=======================================
  Hits        11604    11604           
  Misses       7608     7608           
  Partials      299      299           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 628a349...fed7a25. Read the comment docs.

[cmdcolin]

There is a lot of content out there on CORS errors and s3 but this one stood out to me https://serverfault.com/questions/856904/chrome-s3-cloudfront-no-access-control-allow-origin-header-on-initial-xhr-req

Here is a clue

"When a bucket has CORS enabled, Vary: Access-Control-Request-Headers, Access-Control-Request-Method, Origin should be returned unconditionally by S3 -- even for non-CORS requests -- specifically because varying these will cause an important variation in the response.

Otherwise, browsers (and potentially other caches and CDNs, though not CloudFlont) will incorrectly try to use their cached versions where they should not be used -- specifically, the browser will have a cached response where no Origin header was sent, and will reuse this response for a subsequent request where an Origin header is needed -- resulting in a cross-origin policy violation."

This means the browser might be trying to use a previously cached response for example if you visited the data by plainly visiting the data URL e.g. in my case maybe I visited the URL https://s3.amazonaws.com/jbrowse.org/genomes/hg19/hg19_aliases.txt in the browser and then later Chrome uses that response, which was not visited using a CORS method, and accesses it via the cache, which then results in it thinking Access-Control-Allow-Origin was not set

Answers at that link and https://forums.aws.amazon.com/thread.jspa?messageID=796312 which is linked from there may be an alternative that more generally solves this problem

[cmdcolin]

Might be able to use workaround #2 posted

"Alternative/Hackaround #2: Use a "dummy" query string parameter that differs for HTML and XHR or is absent from one or the other. These parameters are typically named x-* but should not be x-amz-*."

[garrettjstevens]

Hmm, that could maybe explain why using the other S3 path style (i.e. using jbrowse.org.s3.amazonaws.com instead of s3.amazonaws.com/jbrowse.org) sometimes seems to fix it, since the browser doesn't have a cached response for the different URL that it tries to use. It doesn't look like Cloudfront is only fractionally more expensive than S3 (although I could be missing something with the pricing), but that forum you linked made it sound like the problem could recur even on Cloudfront without that Lambda@Edge workaround.

Edit: looks like you just posted about the workaround in the Serverfault link, which I forgot to read...

[cmdcolin]

Implemented a possible workaround to generic-filehandle here GMOD/generic-filehandle#71

[cmdcolin]

anyone is interested in checking out #71 maybe this PR could be changed into a bump to generic-filehandle

[cmdcolin]

Looks like that PR does not work and produces

"Access to fetch at 'https://s3.amazonaws.com/1000genomes/phase3/integrated_sv_map/supporting/CHM1/pacbio/data/aligned_reads.bam.bai' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled." on any track..

[cmdcolin]

Some tracks work but that one, the CHM1 track, fails

Link with x-jbrowse: true
https://www.test-cors.org/#?client_method=GET&client_credentials=false&server_url=https%3A%2F%2Fs3.amazonaws.com%2F1000genomes%2Fphase3%2Fintegrated_sv_map%2Fsupporting%2FCHM1%2Fpacbio%2Fdata%2Faligned_reads.bam.bai&server_enable=true&server_status=200&server_credentials=false&server_tabs=remote&client_headers=x-jbrowse%3A%20true
Returns status 0 (cors error)

Link without x-jbrowse: true
https://www.test-cors.org/#?client_method=GET&client_credentials=false&server_url=https%3A%2F%2Fs3.amazonaws.com%2F1000genomes%2Fphase3%2Fintegrated_sv_map%2Fsupporting%2FCHM1%2Fpacbio%2Fdata%2Faligned_reads.bam.bai&server_enable=true&server_status=200&server_credentials=false&server_tabs=remote

Works

[cmdcolin]

Looks like the generic-filehandle#71 didn't consistently work. The above test-cors demonstrated for me at least that there was something wrong with it not working generally for all links even though some links worked

[cmdcolin]

Could consider the other workarounds discussed in the troubleshooting links posted or just ignore for now

[cmdcolin]

Unfortunately the remaining workarounds specified are server side and cloudfront based not pure s3 based it seems

[cmdcolin]

It seems the best thing to do is to clear cache for this case since it appears to be a case of cross-cache contamination. I will close for now

It might be good if we can create a better warning for CORS errors, probably catching status=0

[cmdcolin]

I created GMOD/generic-filehandle#72 to follow up