Re: lynx-dev GIFs corrupted with mime headers option

[Klaus Weide]

On Tue, 22 Jun 1999, Rob Partington wrote:

> In message <address@hidden>, 
>            Klaus Weide writes:
> > I couldn't reproduce the initial problem, so I won't try to regenerate
> > this one.  If it's similar to the one with \x00, it would depend
> > on how the data arrives (how it's partitioned into network datagrams),
> > which is most different for you.  (I'm usually using a local proxy,
> > which probably ships the headers off in a separate first packet, that's
> > why I wouldn't have seen the \x00 problem.)
> 
> It's not happening now.  I'll see if someone was playing with the webserver
> or if I've done something stupid when I've been checking the files. 
> 
> Looks like your patch fixes the bug, I think.  Time to make the Lynx 
> internals eight-bit clean?

It already is, mostly, where it's necessary, IMHO.
(Otherwise the fix wouldn't have been so small.)

Well, you're not really talking about 8-bit clean, but binary-clean:
don't stumble over embedded \x00 chars.  The 'd'ownload, -source,
(and now, hopefully, -mime_header) all already have that property
(unless someone finds more bugs..), at least for the protocols where
binary data can be expected (http, ftp, ?).  Where lynx can assume
that input is text, \x00 bytes aren't really allowed, It wouldn't
surprise me if some strings got lost or truncated in that kind of
situation.

This doesn't apply to what I assume you are mostly concerned with,
binary in post_data.  That wasn't necessary so far, since post_data
could only come form forms and would always be encoded in some way.

Re 8-bit clean proper, there were some changes recently by me to
imporve this for various protocols (not http), mostly to remove
confusion between \0xFF and EOF.

   Klaus