David Allen <[EMAIL PROTECTED]> writes: <SNIP> > > It's perfectly valid to return the default entry in a cdoc when a > > unknown name is requested. > > Well I guess that depends on how you look at it. I always thought > that the mapfile was something of a hashtable, with names as keys and > CHK's as values. If you look at it like that, it makes no sense that > the default entry would be returned. Of course I guess there are > other ways of looking at it. > yes, it is very reasonable to look at control documents as being like a hashtable, where the names are associated with an action (usually redirecting to another URI, but also possibly a DBR or splitfile). It all depends on what you mean by 'default', though. Some people (apparently the writer of that part of fproxy) took default to mean 'the name to be returned when nothing else matches'. By that frame of mind, returning it when asked for a nonexistent entry is very reasonable.
> I misspoke - I was referring to fetching things through FCP > connections using tools like fcpget rather than the servlet. These > tools can process redirects. > And it's just the way that those tools are written, that they have the same behavior of fproxy in the unknown name case. > Here's my brief case. It really violates the principle of least > suprise for a name that doesn't exist to map to the default file. > Whether or not it's right, some people think of freenet keys sort of > like URIs or pathnames. You definately can't do this type of thing > with URIs or pathnames. You also can't do it with any freenet key > that doesn't require a mapfile lookup somewhere. > (I.e. KSK@foo/bar/hello is not the same thing as KSK@foo/bar/) So why > should mapfiles introduce a strange exception to the way keys are put > together? If the metaphor for freenet is something of an abstracted > filesystem, I think it's pretty clear why this is weird behavior. > I'm sure there's websites that redirect you back to the main page when you 404. I guess we could spec a 'unknown' name in the spec, in addition to the default, so that freesite authors could redirect people to their own custom 404 page. But that's getting complicated. > Also I wonder about strange consequences for users. This effectively > means that even if a link on a freesite is horribly broken, it might > pull up the front page of the freesite which would probably be weird > to say the least for the user. I can see somebody making a case for > the fact that this would be good for users since it provides them with > data they wouldn't have otherwise gotten (they would have gotten a > DNF) but again it's pretty counterintuitive, and as a user, I'd > probably wonder where the hell I was if I clicked on a bad link to > Freenet Forever's help section and ended up looking at the front > page. It's also misleading. As a hypothetical, let's say you wrote a > program to run a dictionary attack against a freesite. (Yes that > would be dumb since you could just fetch the mapfile and know what's > out there, but for the sake of argument...) So you fetch > SSK@pubkey/site//word then SSK@pubkey/site//otherword and so on. > Every single request you make will succeed. Bizarre. > It's a bit suprising, but it's definitely very easy to code, so may just be programmers taking the path of least resistance. > Or look at it the other way - can anybody think of a good reason why > it should be the way it currently is? How does this suprise the user > less than returning a DNF or error would when a nonexistent key is > requested? What value does this provide? > Users really don't like errors. For the same reason that IE does everything it can to either render things reasonably (especially when that's the wrong thing to do), and then gives really evil error messages when the user really did screw up, I think it's fine to return the default entry in a control document. Thelema -- E-mail: [EMAIL PROTECTED] Raabu and Piisu GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
