InformAction Forums

In case of http status code 302, a temporary url is generated, which expires after some time. Flashgot ,as expected, passes on the temporary url to download managers and not the original one. This creates problem in resuming, if link expires, since the actual url is not passed to download manager.
So, is it possible to pass on actual url also to the download manager, so that it can generate the new url from location header, so that resume is possible in case the downloads are paused for relatively longer time. As a test case, the following link returns a url which expires in less than a minute,
http://soundcloud.com/playbackmedia/hai ... w/download
So, if a download is paused for more than a minute, it fails. There is no way of generating the url again, as the original url is never passed on by Flashgot.

adnan wrote: Flashgot ,as expected, passes on the temporary url to download managers and not the original one.

It depends. If you select "FlashGot Link" or perform a "FlashGot Selection/FlashGot All" on the page including it, the original link as it appears in the page is sent.
If you, instead, click on the link and select FlashGot among the handling options, the final URL is sent because is what Firefox can see at that stage.

If you, instead, click on the link and select FlashGot among the handling options, the final URL is sent because is what Firefox can see at that stage.

This is the case most of the times. I suppose it is possible to pass on the actual url also. It is because the address bar still contains the original link. The final url is simply not displayed in the address bar, it is just passed to download client. You can try it. Paste the url http://soundcloud.com/playbackmedia/hai ... w/download in the address bar. The final url is passed on to client, but address bar still contains the original url. If somehow it may also be passed on, if you are interested in doing that.

When you simply click the link, or if you were to paste the link into the address bar, it is your browser which figures out where the actual download link is.

Once it does that, your browsers download dialog appears, with one option on that to FlashGot that link. But at that point in time, the only thing known to FlashGot is the link itself.
After timing out, this will not resume, instead returning a 403 Forbidden.


When you FlashGot the link directly, it is FlashGot that parses the link, not your browser.
This will be able to "resume" because it "regenerates" the link.


(Note the truncated second soundcloud URL ... ???)

FlashGot doesn't seem to pass filename to download managers even if Content-Disposition header is present along with file name in response header. I suppose their is no reason for not doing that.

adnan wrote:FlashGot doesn't seem to pass filename to download managers even if Content-Disposition header is present along with file name in response header. I suppose their is no reason for not doing that.

The file name parameter had been introduced to pass file names that the download manager could never figure out, like the "fake" ones extrapolated from the title of youtube videos (otherwise they would all be named "videoplayback").
Content-disposition can be used by the download manager directly.
Anyway I'm not against checking whether it can be passed as file name when it makes sense.

So are you adding support for it your next version.

adnan wrote:So are you adding support for it your next version.

"When it makes sense" means for single downloads which have already sniffed the request in the browser (otherwise the risk is breaking one-token downloads).
Yes, I'm gonna add it for those.

In accordance to the debian packaging system, i had to change binary name from flareGet to flareget, hence it no more works with flashgot. I hope you would fix that in your next relesase.

I installed FlashGot v 1.4.8.6rc1 and it did not found flareget which I installed from Ubuntu repos. I found out that Ubuntu installs it as /opt/flareget/flareGet and does not add it to the path.
After adding a symbolic link on my path named "flareget" FlashGot was able to detect it. However, on "FlashGot link" all that happens is that flareget is started and/or brought to focus and no URL seems to be passed to it.

The version of flareget available through Ubuntu Software Center, installs flareget in /opt/flareget/flareget , due to which flashgot doesn't detect flareget.
flareget binary has two locations: /usr/bin/flareget and /opt/flareget/flareget (varying with Linux Distros)

adnan wrote:The version of flareget available through Ubuntu Software Center, installs flareget in /opt/flareget/flareget , due to which flashgot doesn't detect flareget.
flareget binary has two locations: /usr/bin/flareget and /opt/flareget/flareget (varying with Linux Distros)

And they're not added to $PATH?

Many users of flashgot posted on my blog that flareGet is not detected by flashgot, if installed from Ubuntu Software Center. So i suppose /opt/flareget/flareget is not detected by flashgot. The output of "echo $PATH" on Ubuntu is:

/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

adnan wrote:Many users of flashgot posted on my blog that flareGet is not detected by flashgot, if installed from Ubuntu Software Center. So i suppose /opt/flareget/flareget is not detected by flashgot. The output of "echo $PATH" on Ubuntu is:

/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

It would be automatically detected if it /opt/flareget/ was included in $PATH or if a link to /opt/flareget/flareget was present in /usr/bin.

I'll try to work-around, but it will require some major plumbing work in the Linux manager support base class.

Why are you installing to opt instead of /usr/bin?