Please see my changes here.

Post-deployment Testing:

• Perform a GET request using curl or postman for the URL below
  • https://translate.bioviz.org/api/?hubUrl=https://api.wenglab.org/screen_v13/hubs/rna22/hub.txt&filePath=/hg38/annots.xml
• Ensure that none of the file elements have name attributes with query parameters.

What happens when igb tries to retrieve the data? Will the server send the data or generate an error?

If the query parameters are necessary to get the requested data, then I think it will probably be necessary to create some kind of proxy server or redirection server on the trackhub facade host site.

How this might work (a suggestion):

• The remote host for the data file expects a URL such as example.com/a_very_weird_path
• The track hub facade realizes this and understands that the format of the file needs to be indicated in a file extension, e.g., "something.bed", in order for IGB to properly request and parse the data (in this case, the format is "BED")
• The track hub therefore provides a different URL to IGB, e.g., translate.bioviz.org/a_very_weird_path/something.bed
• When IGB asks for translate.bioviz.org/a_very_weird_path/something.bed, probably as a byte range HTTP request, the facade host retrieves those data from the remote source using example.com/a_very_weird_path. Like a proxy server, the facade host simply "copies" the HTTP request coming from IGB, substituting the proper URL

Note that the above suggestion is a big change for how we do things, because this could potentially pull a massive amount of data through the facade host, depending on the requests IGB is making. There might be a better way, in which the facade host would instead use a simple redirection to forward IGB's request to the host server, after changing the URL. If this is possible, then the remote host will send the data directly to IGB, without the data having to flow through facade host, which would be wasteful.

I agree that forwarding the request would be better, although to do so, we would need to store a mapping of all data urls that contain query params to their stripped counterparts. This would probably be best achieved by using some sort of database. It might be easier to just update the IGB code to correctly handle these URLs, although I'm not sure how easy this would be. [~aloraine], what do you think?

We will release a new version of IGB that addresses the issue. In light of this, we will hold off on changing the back end code for now.