User talk:Janus/DFFD

DFFD Download Referer Blocking

Is there a reason you don't allow download.php links to work from the wiki? I don't see the need to have the user to view the download page from the page describing it to begin with.

If you could allow that, it would be nice. —Rick 22:56, 23 March 2008 (EDT)

Yeah, that's a quirk with the way browsers handle redirection. The referer is checked for future load balancing between multiple download servers, and a direct link to download.php gives the wrong referer info to the download server after redirection. I've spent quite a lot of time trying to find workarounds for that same issue (I played around with every redirection method available) on another game file hosting site I have, with no success. This other site uses a lot of bandwidth (~2.5TB per month at the moment) and has just such a load balancing scheme to handle all of the downloads.

So, I guess you could say it's a necessary evil. If I removed that restriction now and later have to put it back into place due to load balancing, it could lead to a lot of people needing to change their links then. I think it's better to have it remain consistent from the beginning, after having dealt with people having to update their download links to my other file hosting site. --Janus 23:36, 23 March 2008 (EDT)

Seems it's causing another problem, for me anyways. I'm not using any kind of accelerator or any software firewall (router-based FTW.) I've even tried the download with greasemonkey and AdBlock+ disabled (extra longshot chance, but just to be safe) and still nojoy. With no idea why it's doing it, nor any way that I can get around it, DFFD is useless to me. --Edward 09:35, 22 July 2008 (EDT)

A hardware firewall is very unlikely to mess with the "referer" info sent with an HTTP download request header. It's more likely a setting in your browser if you indeed have no software firewall or download manager/accelerator software.

Follow this link and copy the results of it, then click the link and see if the "referer" changes:

http://dffd.wimbli.com/checkvar.php

Send me that info through the DFFD site's contact form. --Janus 10:29, 22 July 2008 (EDT)

Considering the "Contact" form uses a referral-based submit system, I'm not sure how that was supposed to work out. In either case, I pulled up my about:config settings and found that network.http.sendRefererHeader was set to 0, (as opposed to the default of 2). Probably was set to assist in circumventing some other site's undesired tracking. --Edward 01:13, 26 July 2008 (EDT)

Hmm, yeah, I'd forgotten about that; I had it set that way to minimize bot spam being sent through the contact form. I've switched it to allow blank referers in the contact form.

Changing that hidden Firefox setting would indeed cause the problem. Glad to hear you've got it sorted out. --Janus 04:43, 26 July 2008 (EDT)

Given that I work with anti-spam stuff for a living, comment spam can be almost nullified by a basic CAPTCHA. Referrer blocking tends to cause headaches off and on from overzealous firewalls, browsers with high privacy settings, and other subtle glitches. If you want to have fun, make the captcha output an animal sound (meow, woof, quack, etc) and have the proper response be that animal. Jippen 10:23, 27 July 2008 (EDT)

New version uploads

When uploading a new version of a file, this does not reset the number of downloads and other information. See tweak page for an example, I recently uploaded 1.2.0.0 (old was 1.1.0.0). —Rick 03:11, 31 March 2008 (EDT)

Well, the downloads and views counters not resetting (along with vote data and so forth) is intentional. That way it tracks the data through all versions uploaded. If you want to reset those counters for whatever reason, you can create a new listing and optionally delete the old one.

However, I do need to fix the issue of updated listings not showing up as the latest file in the "Newest Files" RSS feed and on the Statistics page. It's just one of those details I haven't gotten to yet. Thanks for the feedback, I'll try to get that issue fixed in the next few days or so. --Janus 03:29, 31 March 2008 (EDT)

Maybe provide an option for resetting counters when editing a file? —Rick 03:29, 31 March 2008 (EDT)

I came up with and implemented what I think is a better solution, if slightly more complex on the server side. It now tracks both total views/downloads for the listing, and current views/downloads for the current file. Whenever you edit the listing and upload a new file for it, it will reset the current counters to zero. This will of course only take effect when you next upload a new file when editing your listing; listings which haven't been updated with new files will only display the standard listing counters. No files will yet show it on the main DFFD site yet since none have been updated since these changes were put in place, but you can see an example of the new view/download counters in action over on my test site here.

You can see the list of other site updates on my user page here. --Janus 12:40, 3 April 2008 (EDT)

Also, it seems that the different upload mechanism is understandably a little confusing to people used to regular file upload/submission forms in that the file upload is embedded in the submission form and needs to be completed before submitting the listing. I'll modify it to check and see if no file was yet uploaded and give you a message telling you as much if you click the button to submit the listing without uploading. It will be a simple "OK" option if it's a new listing, and a "Submit without uploading new file? Yes/No" option if it's an edit. Probably should have added that modification in earlier. --Janus 04:05, 31 March 2008 (EDT)

I've taken care of this in the site updates listed on my user page. --Janus 12:40, 3 April 2008 (EDT)