inn-2.2 / storageapi + wireformat == corruption

Russ Allbery rra at stanford.edu
Mon Sep 27 01:41:29 UTC 1999


greg andruk <meowing at banet.net> writes:

> While this patch gets the checksums to agree, it contradicts both 1036

> 4.3 Batching

> [...]

>   (The newline at the end of each line of the message is counted as
>   one byte, for purposes of this count, even if it is stored as
>   <CARRIAGE RETURN><LINE FEED>.)

Neither 1036 nor USEFOR apply in this particular situation, so far as I
can tell, since this is actually a question of internal storage formats.
QIO is never used to read articles on the wire.

I see what you're saying, and I don't disagree, but if the article is
stored in wire format then \n isn't a line ending.  If bare \n should
*become* a line ending, then whatever is accepting the data originally
should be converting \n to \r\n as appropriate.

>  4.4.  Characters and Character Sets
>     Transmission paths for news articles MUST treat news articles as
>     uninterpreted sequences of octets, excluding the values 0 (ASCII
>     NUL) and 13 and 10 (ASCII CR and LF, which MUST only appear in the
>     combination CRLF which denotes a line separator).

What this basically seems to translate as to me is that articles
containing bare newlines are invalid articles.  So we're probably entirely
within our rights to simply reject them, the same as we do with articles
with embedded nuls at present.  If we accept them, though, I think we
should pass them along completely unmodified.

I'm happy to implement either, but I don't think the old behavior was
correct.

-- 
Russ Allbery (rra at stanford.edu)         <URL:http://www.eyrie.org/~eagle/>


More information about the inn-workers mailing list