> I don't know if anyone has mentioned this Fproxy quirk: When you click on a > link to a file-type your browser doesn't know about, your node starts > downloading the file while your browser pops up a dialog asking if you want > to download it
Fault of browser, not fproxy. Seems that the browser makes this decision based on the file extension of the URL. For instance, MSK at SSK@p0EFqjmDioSqKmYYORPrClUepi4QAgE/snarfoo//index.html causes a normal load of snarfoo's main page, while MSK at SSK@p0EFqjmDioSqKmYYORPrClUepi4QAgE/snarfoo// causes the download dialog to pop up, because as far as the browser's concerned, the incoming data ain't html. Seems the browser ignores the 'content-type' coming back in the reply header. This is probably why it's become standard practice for freesite links to include the default page. This needs to go into the list of 'good freesite design tips', if there is such a list. I can't see any workaround for this within FProxy. David ----- Original Message ----- From: "Rob Cakebread" <r...@myrealbox.com> To: <devl at freenetproject.org> Sent: Sunday, June 17, 2001 11:55 Subject: Re: [freenet-devl] FProxy must die^H^H^Hget fixed! > On Saturday 16 June 2001 04:35 pm, you wrote: > > Hi, > > I don't know if anyone has mentioned this Fproxy quirk: When you click on a > link to a file-type your browser doesn't know about. Your node starts > downloading the file while your browser pops up a dialog asking if you want > to download it. If you say yes, your browser makes the node do another > request, so you have two going on, cutting your bandwidth in 1/2. This > is mainly a problem for us po' folk with 56k modems. > > > > > > After my previous posts blasting FProxy's quirks, and advocating native > > implementations of http access to Freenet, I am forced to recant somewhat. > > > > Why? > > > > Because FProxy offers the only real anonymity protection. While native http > > portals to Freenet, such as FwProxy, may have performance advantages, plus > > watertight http anonymity security, there is a security hole - web bugs can > > be planted which hit https, ftp, gopher or socks, or some other protocol > > which some goddam browser will allow, and it would require proxies for all > > these protocols, plus compulsory browser proxy configuration, to protect > > anonymity. One slip on user's part could be fatal. > > > > So, back to FProxy. > > FProxy's 'paranoid' filtering is the only way to go. Block anything that > > even remotely smells like an out-of-band hit. Give an inventory of all > > potentially compromising content. I now appreciate the wisdom of this > > approach. > > > > So I'm taking the position now to ask, PLEASE, for FProxy to get fixed up. > > > > One bug to report is that periodically, FProxy 'loses the plot' returns > > 404's on all freenet requests. Restarting the node fixes this. > > Yeah, I get this daily. > > > > Hmm, I'm tempted to attempt a port of FProxy to platform-independent C++. > > Have the cake and eat it too :) > > > > Cheers > > David > > > > > > > > _______________________________________________ > > Devl mailing list > > Devl at freenetproject.org > > http://lists.freenetproject.org/mailman/listinfo/devl > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://lists.freenetproject.org/mailman/listinfo/devl > _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
