Re: lynx-dev file uploads in forms

[Klaus Weide]

On Fri, 3 Dec 1999 address@hidden wrote:

> In message <address@hidden>, 
>            Klaus Weide writes:
> > Well, if it used "quoted-printable" instead of "base64" it would work
> > in more situations.  If it used a C-T-E only when necessary (8-bit chars
> > present), it would work in more situations.
> 
> Good points.  Only using C-T-E where necessary is more difficult.  The code
> is designed to only open the file once and only have one copy in memory at
> the very last point possible (to avoid copying big files around in memory).

Yes, but if that's what it takes to make it (more) usable...

> The problem is that find some 8-bit chars in the last 10 bytes of a 1 Meg
> file would mean scrapping all the work we'd done up to that point.  Oh, for
> multipart/form-data byte-ranges!  So, I guess we have to scan the whole file
> first, for 8-bit chars, then only use C-T-E if necessary.

If you wand to send a ! Meg file as form contents, this should be the least of
your worries... (*How many* copies of post_data does lynx keep in memory?)

> It would have to be an option, though, because I haven't seen many form
> uploads that actually handle C-T-E at all.  I'll have a look at the spec
> for multipart/form-data some more -- I've a vague memory that you can
> specify what kind of data you can accept.  

Only in terms of Content-type afaik, not C-T-E.  Theres an ACCEPT attribute
(and an ACCEPT-CHARSET attribute), but no ACCEPT-TRANSFER-ENCODING attribute.

> If it can accept C-T-E'd data,
> Lynx can be good and 7bit clean.  If it can't, Lynx will just have to
> transfer binary, like the broken browsers.

Well, HTTP is a binary-clean protocol.  It doesn't make too much sense
to impose restrictions that come from the mail world.

I think you don't really do it this way because it's The Right Way, only
because it makes implementation in Lynx (apparently) easier...

I think we (you:)) should introduce a level of indirection, that would
overcome *two* problems (one: lynx treats post_data as C strings -> problem
with '\0' bytes; two: wasteful memory use).

Instead of shuffling around the data in memory as

>> Post Data:
--xnyLAaB03X
Content-Disposition: [ etc. ... ]
--xnyLAaB03X--
>> Post Content Type: multipart/form-data; boundary=xnyLAaB03X

package them in HText_SubmitForm as something like:

>> Post Data: [where-the-data-really-is]
>> Post Content Type: x-lynx/indirect-form-data

(and pack the data into [where-the-data-really-is], of course)

[where-the-data-really-is] could be a file://localhost/tmp/Lblah URL
(keep those 1 Meg files out of memory), or some internal place that
designates a memory buffer (perhaps addressed by a new internal-use-only
URL scheme, lynxmemory:0xnnnnnn, [don't accept this scheme as input from
user or HTML, i.e. make is_url() return 0 for it]).  Make HTLoadHTTP resolve
the reference, read the data (from file, or from buffer) and send it in
binary form, if it detects a post_content_type of "x-lynx/indirect-form-data".

What do you think about this?

> And I'll get around to patching CGI.pm and sending it off to Lincoln Stein.

That would be good anyway.

> > Newer, or older?  It seems at some point there already was a non-encoding
> > version, which got replaced by the unconditional base64 code.  But I
> > haven't followed closely.
> 
> The non-encoding is version 0.2, the unconditional base64 was version 0.1.
> v0.1 works all the time, whereas v0.2 has some issues with the position of
> the file upload field on the form (to do with mishandling first_one which
> leads to the the boundary strings being misplaced).

Umm, do you have any version that is somewhat up to date wrt. current
dev code?  I suspect your patches will continue to lead an obscure existence,
and not have testers, unless you change that.

Your version numbers don't seem to relate immediately to what I see on
<http://lynx.browser.org/rp/#file>.  (An obscure URL, rarely announced.)
The link text

     * [6]Latest form based file upload patch, Lynx2.8.2 (broken)

doesn't look very inviting...

Below that, it has "Please try this patch and report success or failure."
Ok, I'd love to help, but not so much that I'd go back to 2.8.2,  sorry...

   Klaus