On Thu, 18 May 2000 15:07:18 EDT, Jean Bedard <[log in to unmask]> said: > >> We discovered today that bulk ADD operations performed from a > >> Macintosh do not work correctly. The same operations do work from > >> Windows machines... What seems to be happening is the end-of-line > >> character isn't being recognized. The first address in the upload file > >> gets added but the second address (which is on a new line in the file) > > > is appended to the first address. > > What I do is tell my people to use MS Word and save the file in "DOS text" > or "ANSI text", not just "text", before uploading. I don't know if this > problem is Listserv's or the browser's. It's mostly the browser's. The problem is that there are 3 commonly recognized waus to terminate lines. One is with a "CR" carriage return character, the second is with a "LF" linefeed character, and the third is a CR/LF pair. The macintosh browser is presenting the files with just a CR or LF (I can't remember which), and the Listserv end isn't recognizing it. RFC1867 (which defines form-based upload) is a bit fuzzy on what should be done, other than to say in section 5.5 and 5.9: 5.5 Default content-type of field data Many input fields in HTML are to be typed in. There has been some ambiguity as to how form data should be transmitted back to servers. Making the content-type of <INPUT> fields be text/plain clearly disambiguates that the client should properly encode the data before sending it back to the server with CRLFs. 5.9 CRLF used as line separator As with all MIME transmissions, CRLF is used as the separator for lines in a POST of the data in multipart/form-data. However, this mostly applies if the file is uploaded with a text/plain MIME type. If it's application/octet-stream or other similar, all bets are off. It's unclear whether Listserv should be adding a 'ACCEPT="text/plain"' to force the CRLF conversion, which should fix the problem as well... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech