Re: LYNX-DEV problems in form-based file upload

[Foteos Macrides]

Bae Young Hyun <address@hidden> wrote:
>I have been fixing the lynx sources to support the form-based
>file upload function which is a new(?) spec. in HTML 3.0.
>Fote helped me by telling where I should start and which files
>are related to my work.
>I followed his advise. So, I fixed some source files of lynx2-6fm.
>First, I made it possible to understand "<INPUT TYPE="file" ... >" 
>and accept a file name that it will be uploaded. 
>Then, I added some codes into "HText_SubmitForm" procedure in GridText.c
>to construct a form data including the contents of a file.
>
>Since the file upload test site, http://thccy14.oz.nthu.edu.tw:6083/wole/UL,
>doen't work currently, I cannot test file upload of modified lynx yet.
>But, I tested the transmission of the constructed form data using
>the same html file without a cgi binary file, which is specified as 
>the action of the form.
>
>Now, I have two problems.
>The codes in HText_SubmitForm procedure for constructing a form data via
>a data structure of "query", consist of string processing fucntions
>like as strcpy, strcat, or strlen etc. So, when I include a binary file
>into a query structure, I must encode that files using mimencode.
>Is it impossible to do that without any encoding procedure ?
>Can I include bare data of a binary file into a form data whose enctype
>is multipart/form-data without any encoding procedure ?
>
>The next problem seems to be related to the size of an upload file.
>From the results of simple transmission test, it is successful that
>trasmission of a relatively short file. However, I encountered follow
>transmission error message for a larger file.
>
>Alert!: Unexpected network write error; connection aborted.
>Alert!: Unable to access document.
>
>I checked the exact boundary.
>When the total size of "query" structure is larger than 9640 bytes,
>the above messages are displayed and the transmission fails.
>
>For now, I have no idea about these problems.
>Who has the same problems or some solutions ?
>The solution of these problems is very critical to my work.
>I'd like to ask all of you, especially Foteos Macrides, good advises.

        I don't know what might be behind your Content-Length problem,
but it may have to do with buffer sizes in TCPIP software or system
library functions external to Lynx.

        A main reason for having developed the multipart/formdata
ENCTYPE is so that form content can be sent without need to encode
"reserved" and "unsafe" octets, of which a raw binary file is likely
to be full.  That's explained in the file upload IETF RFC, whose URL
I posted.

        The problem for Lynx, though, is that it doesn't yet have
a means of representing disk files in its anchor and form structures
for form content.  What I was planning to do, sometime, is add a
substructure element to the generic anchor structure defined in
HTAnchor.h, and some way of flagging it in the form structures
(and history stack structure).  As explained in the RFC, the
standard, textual form field content is a series of parts in the
multipart overall content, and the file or files associated with
TYPE="file" INPUT(s) are additional parts, unencoded, and with
their Content-Type and other relevant information represented via
MIME headers for its(their) part(s).  That's also important so that
the showinfo ('=') display outputs a representation of the
TYPE="file" INPUT(s), not the actual file content, which could be
an excessively long text file, or a binary file inappropriate to
send to the screen as if it were text.  If you use
ENCTYPE="application/x-www-urlencoded" (the form content default),
then yes, you would have to "urlencode" (i.e., hex escape) the file
(both text and binary, since text files have newline octets which
must be hex escaped) and include it directly in the post_content as
one the of the name=value pairs, but you use
ENCTYPE="multpart/formdata" instead, to avoid such awfullness.

        If you've read the RFC, and that or the above still doesn't
make any sense to you, ask again, trying as best you can to make
explicit what's confusing you (though it's hard to do that when
you don't yet have a complete enough overview of how it all works).

        Otherwise, we can move on to how best to expand the anchor,
form, and history stack structures (which I haven't thought through
yet 8-).  Perhaps Klaus might have some thoughts on that, since he's
been using the LYfoo modules with the richer structures of the v5
libwww.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;