Amazingly enough proff@suburbia.net said:
> No, it isn't. 1.0.6.5 hasn't been heavily tested - that is why it has a .5
> tacked onto the end and there was no announcement. That said, it has only
> one (small) new feature, and a few minor bug fixes - although some of those
> bug-fixes may themselves have introduced bugs. I'd be interested to see
> if you find the same problems with 1.0.6
I did. I didn't have time to debug the problem (or find a work around)
until recently. And, before I did anything, I grabbed the latest version
just incase the problem had been fixed. At anyrate, it seems to be working
fine (execept I just realized I still have the bloody thing pointing to the
wrong directory).
> What kind of insane news-reader insists on using HEAD when XOVER is
> available?
trn 3.6 does for one. I've not delved into the problem too deeply. Maybe
it's fixed with 4.0. I've not played with that yet.
> <shrug> It's completely broken behavior. INN shouldn't do it.
Well, someone else posted that it doesn't. Now, I know I read about that
scheme somewhere before. Maybe it was a different news server, maybe it
was a proposed idea for INN. What I read predates the existence of
dejanews, however, and unless there's another archive of just the
news.software.* heirachy, I probably won't be able to satisfy my curiousity
about what the exact mention was. Actually, now that I think about it,
_maybe_ it was a mention in the overview reference package. I know there
was a justification for it was well.
Ok, I finally figured it out. Looking at this excertp from the INN FAQ:
xhrd and xpat make every effort to use NOV data before they dig the data
out of the actual articles, thus making them considerably faster than
other implementations.
I was on drugs. I was mis remembering that little tidbit. I was probably
thinking at the time that, if those commands are supported that way, HEAD
could be to (with the loss of info, acceptable, IMO).
> Yes, this could be done. But I don't see a call for the added complexity.
> No server worth its salt doesn't support XOVER, and no client worth its
> salt doesn't support fall-back to HEAD.
I just finished reading the entire set of posts to this list. I remember
at least 2, maybe 3 references to servers that don't support XOVER.
But the main concern is readers that, for some reason, user HEAD for some
parts even when XOVER is available. Like I said, when you get into a group
that has 45,000 articles, it's going to kill performance due to the
limitations of the file system.
If HEAD could be streamed similar to the way XOVER could, that would be
great. But you can't. I myself would prefer to have the headers regened
from xover information and have the speed up rather than the full
information found in the real headers.
> XHDR's are handled this way. Where the requested header is not in the
> overview.fmt description for the specified server, nntpcache falls back
> to using XHDR.
Ok, minor bug then. When I tested, I was leaving the ":" off of the
request. I got that from Barber's draft. Specifically, the following
excerpt:
The required parameter is the name of a header line (e.g.
"subject") in a news group article. See RFC-1036 for a list
of valid header lines.
Now, I didn't grab RFC1036 to see if it mentions that the ":" is required.
If I leave off the :, the xhdr is sent back to the server, and it responds
as expected. If I put on the :, nntpcache gets it. I'm not sure if this
is a bug in nntpcache, certain clients, or a ambiguity in the spec that has
been interpreted in 2 different ways.
--
Mike Castle Life is like a clock: You can work constantly
dalgoda@ix.netcom.com and be right all the time, or not work at all
[Note the 4 line .sig] and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
