[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Problems with lynx 2.8.4 (file upload etc.)

From: Frank Heckenbach
Subject: Re: lynx-dev Problems with lynx 2.8.4 (file upload etc.)
Date: Tue, 21 May 2002 21:32:25 +0200

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:


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:

<META http-equiv="content-type" content="text/html;charset=iso-8859-1">
<h1>Download-MenĂ¼ (Lynx Version 2.8.5dev.7)</h1>
<em>Geladener Link:</em>
<em>Vorgeschlagener Dateiname:</em> liste

 auf Disk</a>
 with pager</a>


Frank Heckenbach, address@hidden
GnuPG and PGP keys: (7977168E)

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]