On Sat, Oct 19, 2002 at 07:12:27PM +0200, Oskar Sandberg wrote: > On Sat, Oct 19, 2002 at 12:41:21AM -0400, David Allen wrote: > <> > > Currently, the behavior of fred is to load the default document from a > > mapfile when a nonexistant document name is requested. I.e. > > SSK at Zk3lWHDM6VzA5k4nZWOq5xPl1rkPAgM/FreenetGallery/1//doesnt/exist.txt > > returns the front page. > > This is easy to do at the freenet client level, though it is not > immediately clear how it should fail: by actually failing the entire > request processes at that point, or by treating the parsed metadata as > the last document in the chain. I checked in a patch that does the > former (I hope) - as somebody said the code in > question is in GetRequestProcess. > > I have no idea how fproxy will react to this (considering it's > cludginess level, probably badly), so somebody should test it.
I've given this a shot in build 521, and the same behavior is present through fproxy. Any idea what's going on? As for what the correct response is, unless somebody wants to introduce a new type of error, Data Not Found seems like the best to me. After all, the data wasn't locateable. It's definately not an incorrect URI or anything else like that. A case could be made for "network error" I guess, but that's very non-specific and might it prompt users to keep trying to get that key? I'd really like to have this changed before 0.5 - I'll keep looking in the source myself. Since this was earlier discussed and the metadata spec changed, it would be nice for fred to adhere to its own metadata spec for 0.5. :) -- David Allen http://opop.nols.com/ _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
