JBrowse Error: HTTP 200 when trying to view tracks

I am trying to follow this tutorial here: Genomic Data Visualisation with JBrowse

I am using a local installation of Galaxy v.19.01 and JBrowse 1.16.5+galaxy5. I whitelisted JBrowse and imported the datasets via the links from the tutorial to my history.

JBrows itself seems to run fine, but when I want to look at the results, as soon as I open a track I get the following error messages:

An error was encountered when displaying this track.
Error: HTTP 200 when fetching http://XXXgalaxy/datasets/f0e0bb0fb5(...)/display/data/raw/6aa7a84(...)_0.gff.gz bytes 0-262143

I’d be happy for any tips why this happens and how to solve this.

thanks,

1 Like

Hi,
got the exact same problem on a fresh installed galaxy server.
does anybody know how to fix it ?
regards,
Seb

Same problem here on my galaxy server. This was working for me in Feb and I just noticed the problem now. Galaxy 20.01 and I just upgraded to JBrowse 1.16.9+galaxy0 to see if it would fix the problem.

Hi @galaxyForumAcc, @Seb, @rbatorsky!

I’m sorry for the delayed response here, I didn’t notice this issue previously. I’m one of the two devs and maintainers of that tool.

JBrowse can generate this error when range requests do not work properly. JBrowse makes a request to your galaxy for the datasets, but it only requests the portion that you’re viewing with a header like Range: bytes 0-135. Given that it is making a range request, JBrowse expects to see a 206 Partial Content http return code, but instead it sees 200 OK, as your webserver does not support range requests, and thus returns the whole file.

If you’re using Nginx or Apache, please consider turning on the sendfile mechanism:

Unfortunately this means JBrowse does not always work nicely with development servers, and works best under a proper webserver.

I’ve tested the honour-range option from uwsgi but it seems to have some issues so I have to recommend nginx or apache with sendfile.

Sorry for not seeing this sooner!

Thank you @hexylena for your helpful reply. This sounds like the right direction for me, since I switched from http to uwsgi protocol in the last year and it might be the cause, since in that timeframe JBrowse stopped working for me. I am using apache as a proxy.

However, I switched back from uwsgi to http in both galaxy.yml and my apache config and enabled XSendFile in both places as explained here, and I’m still seeing the same HTTP 200 error in JBrowse.

Edit to add: I made a mistake and had not enabled xsendfile in galaxy.yml. When I do that, I get the error from JBrowse.
Not Found The requested URL /datasets/ab50e8da6b53023e/display/ was not found on this server.

I will keep plugging at this.

A note: I am not able to add the user that runs apache to the galaxy group because of the way the users is set up on my server. This has always been the case for me, even earlier this year when JBrowse was working. I set the umask of the user that runs galaxy to 0022 so that files created are readable by everyone. Do you think that a permissions error could cause this?

Thank you again for any tips.

Hi @rbatorsky!

I am not able to add the user that runs apache to the galaxy group because of the way the users is set up on my server.

ah this can be possibly the cause, if the apache server cannot read the file, then it can’t serve it. are other datasets visible when you access them in galaxy? Or is it just datasets with jbrowse?

Thank you again @hexylena. You’re right, this last bit is a permissions problem. To test I used chmod to open up permissions for a single dataset and then I could see it in JBrowse. I haven’t noticed this problem outside of JBrowse, e.g. I can preview Fastq files and see html from FastQC.

In order to see the display, I needed to chmod o+r for the .dat files associated with the file I was trying to view and the .dat file associated with the JBrowse job, then chmod o+rx dataset_850_files for the files associated with the JBrowse job.

I’ll work on getting my apache user set up so it can be part of the galaxy group. That should fix things.

Thanks again.

@rbatorsky that’s great to hear! I’m glad it could be solved for you.

thank you @hexylena for this help!
it works using the corresponding apache configuration here!