ietf-nntp HDR
Russ Allbery
rra at stanford.edu
Mon Dec 31 17:09:29 PST 2001
Andrew Gierth <andrew at erlenstar.demon.co.uk> writes:
> No, that's _not_ what the OVER response does! As I've explained on
> several occasions, collapsing whitespace in overview headers _does_
> confuse clients (because existing servers don't do it for XOVER, and the
> content of the mandatory overview fields are expected (by clients) to be
> the same for any given article regardless of the server). Currently,
> overview responses _do_ differ when folding or strange control
> characters are present, which is why a) we need to define exactly how
> this should be done and b) we should ensure that for the
> no-control-characters, no-folding case, where current servers all behave
> the same anyway, we should stick with the existing behaviour.
> At some point when we discussed it before, we defined the "overview
> transformation" for any given header as follows:
> - unfold the header by removing all CRLF pairs
> - replace any remaining occurrences of CR,LF or TAB,NUL with spaces
> - leave all other octets intact
> (my server, in addition, removes leading whitespace, and treats bare LF
> as a linebreak in addition to CRLF)
The current draft has:
The content of each field is formed by taking the original content
(such as the raw subject line from the article), removing all US-ASCII
CRLF pairs, and then replacing each remaining US-ASCII NUL, TAB, CR,
or LF character with a single US-ASCII space.
I think that's pretty much perfect, and believe that we should specify the
same thing for HDR. We had a lot of discussion about this for OVER and
arrived at the above as the best approach.
I'm going to draft a replacement for the current HDR section incorporating
this and the other comments that have been posted, since there seem to be
a lot of different little changes to that section.
> Existing practice with XHDR/XPAT is (as I've repeatedly pointed out)
> broken in this respect: some servers (Typhoon and its ilk) behave as
> though the requested header were empty, other servers (e.g. INN, and
> mine) return a 501 error.
> I'd like to be able to allow HDR on arbitrary headers, but at the moment
> it's out of the question for performance reasons.
I think a 503 response is the best approach here, even though it isn't
anyone's existing practice right now. 501 doesn't make any sense, as it's
not a syntax error. 503 seems to be exactly what the situation needs.
--
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the ietf-nntp
mailing list