LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Valdis Kletnieks <[log in to unmask]>
Thu, 18 May 2000 15:51:24 -0400
text/plain (44 lines)
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

ATOM RSS1 RSS2