[cc to lynx-dev added - please keep it on the list] On Tue, 28 Mar 2000 [EMAIL PROTECTED] wrote: > Hi Klaus, > > Thnaks for your thoughts on my post. I received the following > response from the Phorum folks on why Lynx bombs when attempting to post: > > > From: Jason Birch <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [phorum] Browser compatibility > Date: Mon, 27 Mar 2000 22:00:58 -0800 > > I'm not sure exactly what's going on, but for some reason PHP thinks > that the form, as submitted by Lynx, contains a file. Perhaps Lynx > adds a section for a file to the output, even when there is no file > input field. I've tried it, I didn't see lynx send anything that might legitimately be interpreted as sending a file. Try for yourself - turn on trace (^T) before submitting, the Lynx.trace should contain the complete contents of the POST request. (You might want to forward that to the Phorum folks.) Some observations: - Lynx basically ignores the 'type="Button"' field. This shouldn't be a problem. - Does the line-end convention matter (CR vs CR/LF)? Lynx may be sending the textare content differently from what the server expects (but it should handle it robustly). - Lynx may be sending "charset=", can the server deal with it? - Lynx probably sends Content-length, which may not be necessary with a multipart POST. - Are there spurious bytes after the multipart message? (Maybe CR or CRLF not accounted for in the Content-length?) - Lynx collapses the value " Post " into "Post". That should be legitimate. So, there may (or may not) be some peculiarities in what lynx sends; but I don't see why they would result in a server thinking "this is a file upload". > I believe that removing the enctype from the first line > of the form may solve this. Worth a shot anyways... That would be the easy way out... But if there is a problem with Lynx's mutipart/form-data submissions, I'd prefer to understand and solve that problem. [ form sample snipped] Klaus
