On Thu, Mar 31, 2005 at 09:46:19AM -0800, Dave Crocker wrote:
I'm going to conclude that the problem is on
your end (do you perhaps have CRs embedded in the file on that "Fedora"
Linux system instead of native (newline) line endings?) and move on.
As far as I can tell:
1. All of the components involved on my "side" of this are pretty popular, so
serious problems would be expected to have emerged before this.
2. You are the only one having a problem. No one else has reported a problem
with this document, nor with any other document I have generated and made
available in a similar fashion. I've been using these pieces for something
like a year, so I would have expected problems to have been reported by now.
Well, I see the raw CR characters too, but I don't see it as a problem.
I just edit them out. I (too) suspect that Dave is storing the text
file on bbiw.net in "wire format" and not in its native OS format.
It's indeed up to the presentation client to work all this out and show
you the correct text, but I guess some of us aren't fetching the document
using a real viewer. Both 'fetch' and 'wget' retain all of the original
data including CRs -- I guess I wouldn't expect them to translate these
things any more than I would expect them to format an HTML document.
% fetch http://bbiw.net/specifications/draft-crocker-email-arch-04.txt
% wget http://bbiw.net/specifications/draft-crocker-email-arch-04.txt
don't do any presentation formatting, they just fetch the data. However
a real HTTP client has a better chance, so something like:
% lynx -dump http://bbiw.net/specifications/draft-crocker-email-arch-04.txt
local-file
will fetch and format for local presentation (and remove the extra CRs).
And if you really don't trust anything and want to know for sure what's
coming in on the wire, you can snoop with ethereal or tcpdump. Or write
a dumb little program such as the one below, and:
% cd /var/tmp
% cc -o f f.c
% ./f bbiw.net /specifications/draft-crocker-email-arch-04.txt > file
and look at 'file' any way you want to. The CRLFs are there on the wire
and the receiving client may or may not be translating them, depending
on whether it is supposed to.
I hope this has beaten the topic to death :-)
mm
/* f.c -- fetch via HTTP and dump the entire session to stdout
very stupidly.
*/
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <signal.h>
main( argc, argv )
int argc;
char **argv;
{
int pfd; /* fd from socket */
int len;
char *hostP, *fileP;
char buf[1024];
struct hostent *hP; /* for host */
struct sockaddr_in sin;
if ( argc != 3 ) {
fprintf( stderr, "Usage: %s host file\n", argv[0] );
exit( 1 );
}
hostP = argv[1];
fileP = argv[2];
hP = gethostbyname( hostP );
if ( hP == NULL ) {
fprintf( stderr, "Unknown host \"%s\"\n", hostP );
exit( 1 );
}
pfd = socket( AF_INET, SOCK_STREAM, 0 );
if ( pfd < 0 ) {
perror( "socket" );
exit( 1 );
}
sin.sin_family = hP->h_addrtype;
memcpy( (char *)&sin.sin_addr, hP->h_addr, hP->h_length );
sin.sin_port = htons( 80 );
if ( connect( pfd, (struct sockaddr *)&sin, sizeof(sin) ) < 0 ) {
perror( "connect" );
close( pfd );
exit( 1 );
}
sprintf( buf, "GET %s HTTP/1.0\r\n\r\n", fileP );
write( pfd, buf, strlen(buf) );
while ( ( len = read( pfd, buf, sizeof(buf) ) ) > 0 )
fwrite( buf, 1, len, stdout );
close( pfd );
fflush( stdout );
exit( 0 );
}