Subject:
|
Re: Posting problem with the web-interface!
|
Newsgroups:
|
lugnet.admin.general
|
Date:
|
Sat, 8 Jan 2000 06:51:54 GMT
|
Viewed:
|
407 times
|
| |
|
|
In lugnet.admin.general, "Todd Lehman" <lehman@javanet.com> writes:
> [...]
> So it looks like there's a bugaboo somewhere -- possibly related to the
> length of the 'References:' header -- where it inserts a bogus blank line
> between the 'References:' and the 'Subject:' headers.
>
> First thing I need to find out is whether this extra line is being put there
> by the web-client to the NNTP server, or internally by the NNTP server itself
> somewhere...
Ok, I think I've finally got it narrowed down. Looks like there's a
horrible bug in the spawn() function of spawn.c of the NNTP Reference
Implementation.
Here's the loop where it spools stdin out to a tempfile, minus a few
superfluous lines of code:
while (fgets(line, sizeof(line), stdin) != NULL) {
if ((cp = index(line, '\r')) != NULL)
*cp = '\0';
else if ((cp = index(line, '\n')) != NULL)
*cp = '\0';
if (line[0] == '.' && line[1] == '\0')
break;
if (line[0] == '.')
fputs(line+1, fp);
else
fputs(line, fp);
putc('\n', fp);
}
The string buffer 'line' is defined to be NNTP_STRLEN (512) characters long,
which, when used with fgets(), yields a maximum of 511 characters (saving
one for the trailing '\0').
There seems to be 3 reasons that the above while() loop exists: one, it
splits up lines longer than 511 characters into multiple lines; two, it
filters out a couple headers (I snipped that part; it's not relevant to the
bug); and three, it converts \r\n to \n.
Why it splits lines at a 511-character boundary *here* is beyond me...
seems like a really silly place to do this. But that's how it is. Anyway,
it doesn't even split them correctly in all cases. Note that the if/elseif
pair at the beginning of the loop removes \r and \n _sometimes_, but that
after the content of line is written, a trailing \n is written _always_.
So in other words, if a header line just happens to be either 510 or 511
characters long plus a trailing "\r\n" (512 or 513 characters total), then
the second time around the loop for that line, when fgets() is called,
fgets() fetches either "\n\0" or "\r\n\0", respectively, which becomes "\0",
which becomes "\n", thus prematurely ending the header section. :-/
INPUT:
Supercalifragilisticexpealidocious\r\n
Normal\r\n
OUTPUT SHOULD BE:
Supercalifragilisticexpealidocious\n
Normal\n
OUTPUT IS:
Supercalifragilisticexpealidocious\n
\n
Normal\n
I don't know yet whether the "rightest" fix is simply to make 510- and 511-
character lines work OK by not adding the extra newline, or simply not to
split the lines at the 511-character boundary here in the first place.
Actually, looking quickly through RFC's 977 and 850 at
http://info.internet.isi.edu:80/in-notes/rfc/files/rfc977.txt
http://info.internet.isi.edu:80/in-notes/rfc/files/rfc850.txt
I'm confused as to why the lines are even *ever* chopped at 512 by *anyone*.
As far as I can tell, only the *command* lines of the protocol are limited
to 512 characters -- not the content of the posts. Is that right?
--Todd
|
|
Message has 1 Reply:
 | | Re: Posting problem with the web-interface!
|
| (...) I think you are correct. 1038 doesn't seem to specify any limit. The Internet draft at <URL:(URL) suggests 998 as a _minimum_ ("MUST") and lines of arbitrary length as recommended ("SHOULD"). I'm not sure where they got that number from; it (...) (25 years ago, 8-Jan-00, to lugnet.admin.general)
|
Message is in Reply To:
| | Re: Posting problem with the web-interface!
|
| (...) Well, isn't that a fine bunch of potatoes. Hrmrm. Here's what shows up in the dead-articles file on the server (indented with | character)... |X-Nntp-Posting-Host: lugnet.com |Newsgroups: lugnet.off-topic.debate |References: (...) (25 years ago, 8-Jan-00, to lugnet.admin.general)
|
16 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
