Re: lynx-dev lynx: have bug (fwd)

[Klaus Weide]

On Sun, 21 Mar 1999, Leonid Pauzner wrote:
> 21-Mar-99 06:56 Klaus Weide wrote:
> >> Forwarded message:
> >> > From: address@hidden
> >> >
> >> > With lynx 2.8.1 on slackware 3.6, we've seen that the postings to CGI's 
> >> > work
> >> > wrong. It posts Turkish letters wrong, however older versions can post 
> >> > them
> >> > correctly.
> 
> Please add more information:
> try to compare -trace logs between old version and version 2.8.1
> near the point where the problem supposed (sending HTTP request and before).
> Because of a length of trace logs please sent us a relevant fragment only.
> 
> >> > Is this bug been recognized ?
> >> > Is there a patch for it ?
> >> >
> >> > -Turan Yuksel (address@hidden)
> 
> > Please give some more information: an example (of a page with the FORM)
> > with URL; and the settings from Options (.lynxrc) and lynx.cfg that relate 
> > to
> > charsets; and which characters are wrong.
> 
> One certain "problem" I personally run into is a utf-8 URL encoding:
> when HREF= have *open 8-bit text* the remote server (script)
> may (1) expect such bytes %xx-encoded,
> but lynx now (2) translate URLs from document charset to utf-8
> and then sent each byte %xx-encoded (an obvious check -
> a number of %xx encoded bytes increased).

But URLs should never *have* unencoded 8-bit chars - and lynx
never generates such URLs as a result of form submission (I hope).

> UTF-8 URL-encoding was proposed in several recent drafts
> (not handy, but I remember a note that certain protocols
> or servers may expect blind %xx encoding, not utf-8
> so we may need a configurable option between (1) and (2) for compatibility.
> Also I doubt lynx do (2) in all cases, saw it only for HTML's -

It may not do it if in raw or transparent mode, or if Display character set ==
document charset (or assumed charset?), or if CJK, or some other combination
of factors.  It shouldn't have anything to do with HTML or not though.

> a proper solution here may be to not include open 8-bit bytes in HREF=url
> but only %xx-encoded by page authors).

Right, at least for now.   At some point in the future, that may be 
different.

> At least I18N (RFC2070) describe the problem:  [ snipped ]

> > It may not be a bug, but you have to set up lynx correctly.
> > Try it with -raw (or the equivalent '@' key toggle), or with
> > -assume_charset=iso-8859-9 (you possibly also want
> > -assume_local_charset=iso-8859-9).

This could also apply to the UTF-8-in-URLs problem.

But we don't know whether this has anything to do with Turan Yuksel's
problem.  We don't even know yet whether that problem has anything to
do with METHOD=GET forms, the only ones where the data becomes part
of the URL; it might be different for METHOD=POST.

   Klaus