According to Lachlan Andrew: > Greetings again Gilles, > > Thanks for your feedback. I've fixed up some of the > sloppyness in the patch (patch.kurl, relative to > htdig-3.2.0b4-20020922) and done some fairly thorough > testing on it. It now only removes leading slashes if > there are at least the prescribed number. It also stores > the slash count as '0'+slashcount rather than > '\1'+slashcount. That retains the efficiency of using a > single-character, but means that naive reading of the > string gives the correct result (provided slashcount < 10).
Great! I think your new patch is bang on. I'd commit it right now if I wasn't chicken about breaking something just before a snapshot. I'll do it Monday, so we have a chance to test it a bit first (though I assume you've done that already). > I still haven't found out the "right" way to call test/url, > but I have called it by hand, and the results match those > of the original, with one exception. It now normalises the > host name (e.g. resolves aliases) for *all* protocols with > an IP host, rather than just http://. It still only > removes "index.html" from "http://". Yes, I think that was a bug before, and probably shouldn't be kept that way. I don't see why URL.cc should treat http: URLs any differently than https: URLs. Am I missing something, or shouldn't the if (strcmp ((char*)_service, "http") == 0) be changed to if (strncmp ((char*)_service, "http", 4) == 0) ? Similarly, I see a couple lines in the URL::URL() constructor that treat http: as a special case, which should likely be changed. As it stands, any URL of the form service:relative/path will be parsed without regard to the parent URL, unless service is http. I'm sure that's wrong for https, and it may be wrong for other services too. Comments? > I have also expanded the tests in test/url.cc to test the > new functionality, and to test alias resolution. The patch > is in "patch.test". It would be good to have a file of the > "correct" output of this file so that changes to URL.cc > could be tested simply with diff, but I didn't know how > to put that in the patch. That's a good point. As far as I can tell right now, though, the Makefile in the test subdirectory will build url.cc but it won't run it. I think the thing to do would be to write a t_url script, similar to the other t_* scripts, and put all the tests and diffing you want in there. t_url would then need to be added to the TESTS list in Makefile.am, and url.output (or whatever you call it) would be added to EXTRA_DIST. I've never played around with stuff in the tests directory, so I can't say for sure that I'm not missing something. > In the process of testing, I noticed that double slashes > ('//') are normalised out *after* resolving '../'. This > means that '/foo//../' resolves to '/foo/', when UNIX would > resolve it to '/'. Is the current behaviour deliberate, or > an oversight? I'd say almost certainly an oversight. I guess the test above would tell you whether changing it breaks anything. If I recall, the double slash removal was added as an afterthought, so I don't think a lot of thought went into placing it exactly in the right spot in the order of processing. As I mentioned before as well, this feature needs to be configurable, as some non-filesystem URLs need double slashes to remain intact. > Finally, what is the schedule/criterion for the release of > 3.2.0b4? The KDE team won't base their code on snapshots, > and so I'd like to expedite this... Which of the items in > Geoff's regular "current status" posts have to be addressed > before the release? There's no schedule as such. The standard line is "when it's ready." The STATUS file hasn't been updated in quite some time, although Geoff has begun updating it again today. The only items that MUST be addressed before a beta release are the "showstoppers". However, Geoff has set a few goals for 3.2.0b4, not listed in STATUS (yet), which will have to be done before release. These are, at the very least, the mifluz code update and merging in all 3.1.6 fixes and features that are applicable. I think the new query parser may have been a goal too. I think we need to get an "official" list of these, though, so we're all on the same page. -- Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada) ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ htdig-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/htdig-dev