lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Links works, Lynx doesn't work with this submit form. But w


From: Klaus Weide
Subject: Re: lynx-dev Links works, Lynx doesn't work with this submit form. But why?
Date: Mon, 7 Aug 2000 14:20:49 -0500 (CDT)

On Sun, 6 Aug 2000, Frédéric L . W . Meunier wrote:

> Hi. Another strange problem. Tested using Lynx 2.8.4dev.6 and Links 0.92.
> 
> URL: http://www.ibazar.com.br/sellinp.cgi?CodeCat%3DAI
> Problem: Lynx doesn't recognize my account
> 
> Test with Lynx:
> 
> - Go to http://www.ibazar.com.br/sellinp.cgi?CodeCat%3DAI
> - Type pervalidus at Pseudônimo
> - Submit it with Continuar
[...]

> Is this a broken HTML? If yes, where, so I can tell them.

No, broken handling on the server side of the submitted data.

> BTW, another broken application is running at www.slackware.com.
> Their version of Phorum doesn't work with Lynx.
> You always get
>    Warning: File upload error - no name component in content disposition
>    in /var/www/slackware/forum/post.php3 on line 195
>    Warning: Cannot add more header information - the header was already
>    sent (header information may be added only before any output is
>    generated from the script - check for text or whitespace outside PHP
>    tags, or calls to functions that output text) in
>    /var/www/slackware/forum/post.php3 on line 13
> 
> submitting text at http://www.slackware.com/forum/

(I have not tested submitting anything in the second case, but looked at
the HTML for the form itself.)

Both cases have to do with FORMs with enctype="multipart/form-data".
Both seem to use software on the server side that is based on PHP.
I believe that the problems come from PHP's broken parsing of header
fields in the body parts of the multipart/form-data.  It only seems
to understand the headers when they are in a specific format that happens
to be generated by most other browsers, it doesn't understand variations
that should be equivalent.  And it doesn't produce a useful error
message in that case.

I would guess the PHP authors have coded the multipart/form-data parsing
without any reference to applicable standards, just based on observed
data streams that some clients happen to produce.

See here:
   Linkname: Debian Bug report logs - #58235
        URL: http://www.debian.org/Bugs/db/58/58235.html


> No problem with Links. Problem explained at
> http://www.phorum.org/support/read.php?f=1&i=282&t=280

I don't think that "The content-type in the <FORM> definition is wrong"
is a valid description of the problem.

The first case (and maybe the second) also involves type="file" form
input, which is either unimplemented ot broken in current lynx.  But it
doesn't seem that that in itself is the problem.  Links seems to implement 
file upload btw.

I am working on correcting the file upload problems in lynx and have
working code; I hope to make it available soon.  However, that probably
won't affect the interoperability problem with PHP-based software.

(My statements about PHP are based on some playing with PHP3 locally
that I did a while ago.  I don't know which versions of PHP are affected
or whether it has been fixed in some version.  I have not reported this
as a PHP problem anywhere since I've never used PHP except for that
test installation.)

 Klaus


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]