Re: lynx-dev file uploads and content-transfer-encoding

[Klaus Weide]

On Mon, 3 Jul 2000, H. Nanosecond wrote:

> Hello,
> 
> Lynx 2.8.3.rel1 with file-uploads enabled in configure
> sends the files base64 encoded, but there is no content-transfer-encoding
> tag givin. You can see this, for example, at 
> http://www.htmlhelp.com/tools/validator/upload.html if you use tracing
> (Control-T), and RFC 1521 says
> 
>    bAsE64 are all equivalent.  An encoding type of 7BIT requires that
>    the body is already in a seven-bit mail-ready representation.  This  
>    is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is
>    assumed if the Content-Transfer-Encoding header field is not present.
> 
> and 7bit is equivalent in this case to 'none' which I believe is not correct.
> 
> (Although I did a telnet to htmlhelp.com and sent this header and it
> still didn't work)

I am surprised that you can do anything with file-upload at all.
To the best of my knowledge, the implementation is buggy and incomplete.
IIRC, RP (the original author) promised an update around the beginning
of this year, but it hasn't happened.

Sending base64 without telling so in the header is definitely wrong.
But apart from that, I doubt that many servers understand any (non-
identity) Content-transfer-encoding anyway, no matter what RFCs say.
We should be able to send arbitrary binary content without any encoding -
HTTP is a binary-clean transport that doesn't have the same limitations
as mail, after all.  But the file-upload code doesn't do that because
of the way 'post_data' is kept and passed around in the lynx code (It's
a C string, so included NUL characters would screw it up).  Handling
it properly as binary data would require more changes.

  Klaus


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