Thomas Dickey wrote: > On Sat, May 18, 2002 at 06:18:42AM +0200, Frank Heckenbach wrote: > > Thomas Dickey wrote: > > > no - my fixes were addressing a complaint that some sites did not accept > > > the mime-encoded data, and comparing against netscape decided that was > > > the issue. Possibly as you suggest, the MIME headers are missing, but > > > at least plain text can be uploaded (limited testing). > > > > I think that's still the case in 2.8.5dev.7. I'm not sure which > > kinds of files lynx encodes -- I had thought no files at all needed > > to be encoded, provided a non-conflicting MIME boundary was chosen, > > but I may be wrong. Anyway, there still don't seem to be any MIME > > headers referring to the encoding, so uploading only works with > > non-encoded files now. > > agree - then I need to find a good reference for how the headers should be > setup for uploading with MIME encoding.
The `Content-Transfer-Encoding: base64' in GridText.c might be enough already. Though I don't know the details of the relevant RFCs, at least I'd know how to handle it in my CGIs, so it would at least be better than now when there doesn't seem to be any way to notice the encoding. > (The MIME boundary that I think > you're referring to is hardcoded - not good, but not necessarily the > source of the problem). It's certainly the root of one problem. If the file contains the boundary at the start of the line, it gets truncated, e.g. the following file: foo --xnyLAaB03X bar appears as just `foo'. One solution would be to check whether the file contains the boundary and if so, encode it. Another, maybe easier one, would be to add enough random characters to the boundary, so a conflict is "almost impossible". > > It's not unlikely that some sites won't be able to deal with encoded > > files at all -- in fact, my own CGIs don't since I didn't even think > > of the possibility of encoding before and I hadn't encountered it so > > far. I'll add it in my programs (as soon as lynx supports the MIME > > headers so I can test it), but some other sites might not. So it > > might in fact be better if lynx won't encode any files (unless there > > are problems with non-text files that I'm not aware of). > > things like carriage-return/line-feed sequences would tend to be garbled I don't know. My version of Netscape (under Linux) doesn't seem to encode any files, including binaries, and I've had no problems about it so far. But I have no experience on Dos based systems. And another bug, present in 2.8.5dev.7, not in 2.8.4rel.1: Downloading seems to be broken. It does not save the right file, but rather the contents of the download page, like this: <html> <head> <META http-equiv="content-type" content="text/html;charset=iso-8859-1"> <title>Download-Men�</title> </head> <body> <h1>Download-Men� (Lynx Version 2.8.5dev.7)</h1> <pre> <em>Geladener Link:</em> http://127.0.0.1/ferak/intern-2002/liste/ <em>Vorgeschlagener Dateiname:</em> liste Download-Optionen: <a href="LYNXDOWNLOAD://Method=-1/File=/var/tmp/a16041/a16041.html/SugFile=liste">Speichern auf Disk</a> <a href="LYNXDOWNLOAD://Method=0/File=/var/tmp/a16041/a16041.html/SugFile=liste">View with pager</a> </pre> </body> </html> Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E) ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
