David Allen <mda at idatar.com> writes: > On Sat, Oct 19, 2002 at 07:12:27PM +0200, Oskar Sandberg 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. > > > I've given this a shot in build 521, and the same behavior is present > through fproxy. Any idea what's going on? > Yes. The problem is that metadata processing is a bit more complicated than it looks. most URIs in freenet are DBR mapfiles; so when you fetch their key of SSK at blah/name//file.html, the node does: 1a) request SSK at blah/name 1b) parse the cdoc and try to match "file.html" with a document 1c) fail to match, act on the _default_ date-calculated redirect 2a) request SSK at blah/name-date 2b) parse the cdoc, match "file.html" with a document 2c) redirect to the actual uri: CHK at blah2 3a) request CHK at blah2 3b) notice the CHK has no metadata, so don't process anything The problem isn't that the default document is matched in step 1c, as that's necessary for proper functioning of DBRs; the problem is that if file.html wasn't in the cdoc at step 2b, when the final document was retrieved, "file.html" would still be sitting there waiting to be matched. (yes, this does mean one can have a URI like SSK at blah/name//section1//file.html) > 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 disagree, I think it is a problem with the URI, and a InvalidURI response is very appropriate. > 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/ This detail of the metadata spec isn't really a big sticking point. If you want to muck about in the code and think you can produce a clean patch to fix things, look in GetRequestProcess.java in the getNextRequest method. That's where hobx was mucking about to fix this. Thelema -- E-mail: thelema314 at bigfoot.com Raabu and Piisu GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
