Can't load BAM file into web version of IGV

[Simon Andrews]

I saw another post with similar problems but since the symptoms aren't exactly the same I'm posting separately.

I'm trying to load a BAM file into the IGV web app from a URL.  I'm using a custom genome and I've generate the FA/FAI/BAM/BAI files needed.

I can load all of the files into a local IGV browser, pointing them to the URLs, but I can't make this work in the IGV web app.  The genome loads OK, but the BAM files won't.

When I look in the console of the IGV session I see the following error:

Error: BAM header errror: bad magic number. This could be caused by either a corrupt or missing file.

    decodeBamHeader igv.esm.js:37514

    readHeader igv.esm.js:37494

igv.esm.js:26341:24

    loadFeatures igv.esm.js:26341

I've checked the file and the header on it is definitely correct:

$ zcat Nakhuda_s8q_4_TRLT-3HA_Linear_2000_sorted.bam | xxd | head -1
00000000: 4241 4d01 fe01 0000 4048 4409 564e 3a31  BAM.....@HD.VN:1

I know there are some constraints on the headers which need to be present on the web request for the app to work, but I thought I'd added everything which was needed.

If you want to try this the links to the various files I'm trying to use can be seen at:

https://www.bioinformatics.babraham.ac.uk/autoalign/autoalign/view_results/YWJYJEKRFJMXATNUWUAE

I'm not sure what else to try, so any additional suggestions are very welcome, thanks

Simon.

[Simon Andrews]

OK, fixed it.  I found the documentation for the web headers, which said that I needed to add a custom mime-type for the BAM files as they were being served as a gzip type, which caused something along the chain to break.  Serving them as application/octet-stream did the trick

[igv-help]

Thanks for letting us know.

[igv-help]

Hi, yes thanks for letting us know.   Just some clarification for those that might find this thread.    The issue arises if the server reports the content for a BAM file as encoded with gzip (header Content-Encoding: gzip).   This is not correct!   The consequence is the browser gunzips the content before the IGV application even sees it.   IGV then gets a series of unexpected bytes resulting in the magic number check failure.    I have only seen this with Apache servers, but not all Apache servers, in fact the majority of Apache instances do the correct thing.   Explicitly setting the mime type for a BAM file fixes the problem.

-- Jim