From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 BuildID: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 a webpage that submits a form using method "post" does not actually post the data, but opens the messenger with an empty email. Clicking send delivers (of course) just an empty mail. The problem is _not_ in the code of the page, since all other browsers I tried (netscape 4, lynx, w3m, konqueror) work as expected, posting the form data. The problem does occur with both mozilla 0.9.3 and 0.9.5. I also reproduced it with a PDF-form (see example at http://rulbii.leidenuniv.nl/pdfform.pdf) Here the same holds true: it opens the messenger with an empty email on mozilla 0.9.5 (I did not test this on mozilla 0.9.3, since that machine doesn't have the nppdf.so plugin installed), but it works fine under a number of other browsers (I tried several machines too, all linux though). Reproducible: Always Steps to Reproduce: 1.open the webpage or pdf-file (the latter requires the nppdf.so plugin) 2.fill in arbitrary data 3.press on submit Actual Results: the messenger opens with an empty email message (i.e. it doesn;t even contain the form data) Expected Results: the form data should have been POSTed by email "under the hood"
There are 2 sides on this bug : - the fact that a messenger window opens (which N4.* didn't do) - the fact that the messenger-window is empty ( bug 61893 ) (short answer) What you're really reporting here, is a actually a HUGE security hole in older browsers. At this moment, Mozilla doesn't support it (although probably not intentionally :-), but since it's pretty common practice among older browsers, it will probably be supported sooner or later. But only the 2nd case, not the 1st one (see below). The real solution is to support proper cgi's on your webserver, not transporting all kinds of form-data 'under the hood' with a mailer. Don't forget that the mailto-protocol isn't always available (on anonymous web-terminals for instance). And passing data to mailto-handler's isn't defined in any standard anyway (post'ing is HTTP, not SMTP). (long answer) You're expecting that this data is passed 'under the hood', without putting up a messenger-window. I'm strongely opposed to that, because it is this method that is used to collect email-addresses all over the world. You're forgetting that this email is marked with your email-address, and that you have no chance to control what's happening with your data. If it was a real invisible process, then it would be illegal in many countries (definitely in the European Union). Netscape 4.7 throws up some kind of warning dialog, but still without showing you what is being transmitted. I guess they had to do that because of privacy concerns, maybe because of legal problems in certain countries (France I guess, maybe the USA too). I guess that bug 61893 will be fixed some day , and then we'll see that data in the messenger window, so we can inspect it, and refuse to send the email if necessary (or send it anonymously). But the window has to appear, no data can be passed 'under the hood'. Personally, I wouldn't want to fix this bug, but for backwards compatibility (it's used in a *lot* of business intranetsites), I guess we'll have to support it one way or another. I just hope that we won't have a privacy problem here. This means that we'll have to be able to inspect the data, or be able to pass the data anonymously. At the very least we should have a warning with a 'remember decision' policy. But even then, I would still recommend to implement your webpage the *proper* way, with a cgi-handler. A huge amount of webbrowsers have no access to smtp-servers (web-terminals for instance), or are not configured correctly. This means that these people won't be able to use your webpage. Implementing with a regular cgi-page (post or get) solves this.
*** This bug has been marked as a duplicate of 61893 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.