Greetings,
I have a Galaxy tool we use to send files to another website - I used "data_destination/epigraph.xml" as a template. In this case, the other website is our own web-based database system. Everything is on our own internal network. This was working fine until I recently did a major Galaxy update. We were running a large production pipeline, and intentionally did not upgrade Galaxy for over a year.
The problem seems to be when the outside system uses the "DATA_URL" parameter to get the file from Galaxy. Instead of getting the data file, Galaxy returns a HTML file (which seems to be the index page of Galaxy itself). I did a couple tests, and realized that this behavior changes depending on the client using the "DATA_URL". It works in a browser, but fails in other cases:
1) If I take the "DATA_URL", and paste it directly into a browser address bar (Firefox), it works properly. I get the data file I'm supposed to get. 2) In the case of my outside database system, it uses PHP's "copy" function. What gets copied is the incorrect HTML file. 3) I tried using "wget" with the "DATA_URL", and it also gets the same incorrect HTML file. You can see in the wget output that it receives a redirect - the redirected URL turns out to the be galaxy homepage.
So maybe PHP's copy function and wget are both getting redirected, but Firefox is not...? I'll attach the wget output, as well as the incorrect HTML file I'm getting from Galaxy.
Any help is greatly appreciated. Thanks Chris Zaleski
Hello Chris,
It's difficult to determine why you are seeing different behavior between wget and pointing a browser to the url.
What is the url that you have when you mouse over the eye icon in the history item? The current code base encodes the dataset id when you mouse over the eye icon, but the display method supports both encoded and decoded dataset ids for backwards compatibility.
Can you make sure that you are using the same url (that you have for the eye icon) for both directing your browser and your wget call?
Thanks,
Greg
On Nov 15, 2010, at 3:28 PM, Chris Zaleski wrote:
Greetings,
I have a Galaxy tool we use to send files to another website - I used "data_destination/epigraph.xml" as a template. In this case, the other website is our own web-based database system. Everything is on our own internal network. This was working fine until I recently did a major Galaxy update. We were running a large production pipeline, and intentionally did not upgrade Galaxy for over a year.
The problem seems to be when the outside system uses the "DATA_URL" parameter to get the file from Galaxy. Instead of getting the data file, Galaxy returns a HTML file (which seems to be the index page of Galaxy itself). I did a couple tests, and realized that this behavior changes depending on the client using the "DATA_URL". It works in a browser, but fails in other cases:
- If I take the "DATA_URL", and paste it directly into a browser address bar (Firefox), it works properly. I get the data file I'm supposed to get.
- In the case of my outside database system, it uses PHP's "copy" function. What gets copied is the incorrect HTML file.
- I tried using "wget" with the "DATA_URL", and it also gets the same incorrect HTML file. You can see in the wget output that it receives a redirect - the redirected URL turns out to the be galaxy homepage.
So maybe PHP's copy function and wget are both getting redirected, but Firefox is not...? I'll attach the wget output, as well as the incorrect HTML file I'm getting from Galaxy.
Any help is greatly appreciated. Thanks Chris Zaleski <html_file.txt><wget_output.txt>_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Hi Greg,
Using one particular file as an example, the "DATA_URL" parameter received by the 3rd party website (my database system) looks like this: *http://verona/datasets/26044/display* When I mouse over the eye icon in the history item (for the same file/dataset), the URL is this: *http://verona/datasets/46d510dbd81a7315/display/?preview=True*
However this doesn't seem to be related to the problem... I just tried the same procedure on your public site - I sent a small dataset to Epigraph. The DATA_URL parameter was the following: * http://main.g2.bx.psu.edu/datasets/1979577/display*. And when I use wget on this URL, it works correctly! No redirection.
The problem is obviously specific to our setup. Maybe in the Apache configuration? I'll keep banging my head on this, but I'd certainly appreciate any thoughts or suggestions.
Thanks again, Chris
On Wed, Nov 17, 2010 at 3:44 PM, Greg Von Kuster greg@bx.psu.edu wrote:
Hello Chris,
It's difficult to determine why you are seeing different behavior between wget and pointing a browser to the url.
What is the url that you have when you mouse over the eye icon in the history item? The current code base encodes the dataset id when you mouse over the eye icon, but the display method supports both encoded and decoded dataset ids for backwards compatibility.
Can you make sure that you are using the same url (that you have for the eye icon) for both directing your browser and your wget call?
Thanks,
Greg
On Nov 15, 2010, at 3:28 PM, Chris Zaleski wrote:
Greetings,
I have a Galaxy tool we use to send files to another website - I used
"data_destination/epigraph.xml" as a template. In this case, the other website is our own web-based database system. Everything is on our own internal network. This was working fine until I recently did a major Galaxy update. We were running a large production pipeline, and intentionally did not upgrade Galaxy for over a year.
The problem seems to be when the outside system uses the "DATA_URL"
parameter to get the file from Galaxy. Instead of getting the data file, Galaxy returns a HTML file (which seems to be the index page of Galaxy itself). I did a couple tests, and realized that this behavior changes depending on the client using the "DATA_URL". It works in a browser, but fails in other cases:
- If I take the "DATA_URL", and paste it directly into a browser address
bar (Firefox), it works properly. I get the data file I'm supposed to get.
- In the case of my outside database system, it uses PHP's "copy"
function. What gets copied is the incorrect HTML file.
- I tried using "wget" with the "DATA_URL", and it also gets the same
incorrect HTML file. You can see in the wget output that it receives a redirect - the redirected URL turns out to the be galaxy homepage.
So maybe PHP's copy function and wget are both getting redirected, but
Firefox is not...? I'll attach the wget output, as well as the incorrect HTML file I'm getting from Galaxy.
Any help is greatly appreciated. Thanks Chris Zaleski
<html_file.txt><wget_output.txt>_______________________________________________
galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Chris Zaleski wrote:
Hi Greg,
Using one particular file as an example, the "DATA_URL" parameter received by the 3rd party website (my database system) looks like this: *http://verona/datasets/26044/display* When I mouse over the eye icon in the history item (for the same file/dataset), the URL is this: *http://verona/datasets/46d510dbd81a7315/display/?preview=True*
However this doesn't seem to be related to the problem... I just tried the same procedure on your public site - I sent a small dataset to Epigraph. The DATA_URL parameter was the following: * http://main.g2.bx.psu.edu/datasets/1979577/display*. And when I use wget on this URL, it works correctly! No redirection.
The problem is obviously specific to our setup. Maybe in the Apache configuration? I'll keep banging my head on this, but I'd certainly appreciate any thoughts or suggestions.
One quick way to figure out whether it's Apache would be to stop your Galaxy server and try the request - if you still receive the redirect, it's coming from Apache.
However, I think that's unlikely given the request parameters which are being added to the URL and the transformation to /root.
--nate
Thanks again, Chris
On Wed, Nov 17, 2010 at 3:44 PM, Greg Von Kuster greg@bx.psu.edu wrote:
Hello Chris,
It's difficult to determine why you are seeing different behavior between wget and pointing a browser to the url.
What is the url that you have when you mouse over the eye icon in the history item? The current code base encodes the dataset id when you mouse over the eye icon, but the display method supports both encoded and decoded dataset ids for backwards compatibility.
Can you make sure that you are using the same url (that you have for the eye icon) for both directing your browser and your wget call?
Thanks,
Greg
On Nov 15, 2010, at 3:28 PM, Chris Zaleski wrote:
Greetings,
I have a Galaxy tool we use to send files to another website - I used
"data_destination/epigraph.xml" as a template. In this case, the other website is our own web-based database system. Everything is on our own internal network. This was working fine until I recently did a major Galaxy update. We were running a large production pipeline, and intentionally did not upgrade Galaxy for over a year.
The problem seems to be when the outside system uses the "DATA_URL"
parameter to get the file from Galaxy. Instead of getting the data file, Galaxy returns a HTML file (which seems to be the index page of Galaxy itself). I did a couple tests, and realized that this behavior changes depending on the client using the "DATA_URL". It works in a browser, but fails in other cases:
- If I take the "DATA_URL", and paste it directly into a browser address
bar (Firefox), it works properly. I get the data file I'm supposed to get.
- In the case of my outside database system, it uses PHP's "copy"
function. What gets copied is the incorrect HTML file.
- I tried using "wget" with the "DATA_URL", and it also gets the same
incorrect HTML file. You can see in the wget output that it receives a redirect - the redirected URL turns out to the be galaxy homepage.
So maybe PHP's copy function and wget are both getting redirected, but
Firefox is not...? I'll attach the wget output, as well as the incorrect HTML file I'm getting from Galaxy.
Any help is greatly appreciated. Thanks Chris Zaleski
<html_file.txt><wget_output.txt>_______________________________________________
galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
galaxy-dev@lists.galaxyproject.org
-
Chris Zaleski -
Greg Von Kuster -
Nate Coraor