63050 - flash plugin submits garbage from a flash form

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P1)

Description

[wgollino]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001215
BuildID:    2000121520

When you fill out a form created in flash (ie. in a flash .swf), mozilla submits
garbage to the server. Instead of doing a proper POST, it sends bad headers to
the server, along with some garbage characters.

Reproducible: Always
Steps to Reproduce:
1. Go to http://www.emailtrack.com/
2. Enter any username and any password.
3. Click on 'Login'

Actual Results:  The server responds with:
---------------------------------------------------------------------
Bad Request

Your browser sent a request that this server could not understand.

Request header field is missing colon separator.

°m(èÑB1

Apache/1.3.12 Server at www.emailtrack.com Port 80


Expected Results:  Mozilla should submit the form data using post, directly to
the page http://www.emailtrack.com/public/login.html.

It works properly in Netscape 4.7x and IE 4.x, 5.x. This problem is also present
in Netscape 6.0 under Windows 98 and NT 4.

Comment 1

[shrirang khanzode]

dunno if this is similar to bug 60722. Confirming this problem for the time 
being as I see it on win trunk build 20001214.

Comment 2

[karnaze (gone)]

Moving to m0.9 and reassigning to peterl.

Comment 3

[Peter Lubczynski]

I need a more simplified testcase than this. Anyone know flash? I'll write the 
CGI part.

Comment 4

[shrirang khanzode]

Attachment: flash form submission testcase

Comment 5

[Peter Lubczynski]

I stepped through plugin code and everything looks fine but the Windows 2000 
Network Monitor does reveal the garbage in the POST session:

00000030                    50 4F 53 54 20 2F 63 67 69 2D       POST./cgi-
00000040  62 69 6E 2F 66 6C 61 73 68 6D 61 69 6C 3F 41 6D bin/flashmail?Am
00000050  61 6E 64 61 2B 74 66 61 72 72 40 77 74 2E 6E 65 [e-mail]
00000060  74 2B 68 74 74 70 3A 2F 2F 77 77 77 2E 76 69 72 t+http://www.vir
00000070  74 75 61 6C 2D 66 78 2E 6E 65 74 20 48 54 54 50 tual-fx.net.HTTP
00000080  2F 31 2E 31 0D 0A 52 65 66 65 72 65 72 3A 20 68 /1.1..Referer:.h
00000090  74 74 70 3A 2F 2F 62 75 67 7A 69 6C 6C 61 2E 6D ttp://bugzilla.m
000000A0  6F 7A 69 6C 6C 61 2E 6F 72 67 2F 73 68 6F 77 61 ozilla.org/showa
000000B0  74 74 61 63 68 6D 65 6E 74 2E 63 67 69 3F 61 74 ttachment.cgi?at
000000C0  74 61 63 68 5F 69 64 3D 32 38 39 31 33 0D 0A 48 tach_id=28913..H
000000D0  6F 73 74 3A 20 77 77 77 2E 65 6E 65 74 73 65 72 ost:.www.enetser
000000E0  76 65 2E 63 6F 6D 0D 0A 55 73 65 72 2D 41 67 65 ve.com..User-Age
000000F0  6E 74 3A 20 4D 6F 7A 69 6C 6C 61 2F 35 2E 30 20 nt:.Mozilla/5.0.
00000100  28 57 69 6E 64 6F 77 73 3B 20 55 3B 20 57 69 6E (Windows;.U;.Win
00000110  64 6F 77 73 20 4E 54 20 35 2E 30 3B 20 65 6E 2D dows.NT.5.0;.en-
00000120  55 53 3B 20 30 2E 38 2E 31 29 0D 0A 41 63 63 65 US;.0.8.1)..Acce
00000130  70 74 3A 20 2A 2F 2A 0D 0A 41 63 63 65 70 74 2D pt:.*/*..Accept-
00000140  4C 61 6E 67 75 61 67 65 3A 20 65 6E 0D 0A 41 63 Language:.en..Ac
00000150  63 65 70 74 2D 45 6E 63 6F 64 69 6E 67 3A 20 67 cept-Encoding:.g
00000160  7A 69 70 2C 64 65 66 6C 61 74 65 2C 63 6F 6D 70 zip,deflate,comp
00000170  72 65 73 73 2C 69 64 65 6E 74 69 74 79 0D 0A 41 ress,identity..A
00000180  63 63 65 70 74 2D 43 68 61 72 73 65 74 3A 20 49 ccept-Charset:.I
00000190  53 4F 2D 38 38 35 39 2D 31 2C 20 75 74 66 2D 38 SO-8859-1,.utf-8
000001A0  3B 20 71 3D 30 2E 36 36 37 2C 20 2A 3B 20 71 3D ;.q=0.667,.*;.q=
000001B0  30 2E 36 36 37 0D 0A 4B 65 65 70 2D 41 6C 69 76 0.667..Keep-Aliv
000001C0  65 3A 20 33 30 30 0D 0A 43 6F 6E 6E 65 63 74 69 e:.300..Connecti
000001D0  6F 6E 3A 20 6B 65 65 70 2D 61 6C 69 76 65 0D 0A on:.keep-alive..
000001E0  D8 12 0B 10 01 00 00 00 B0 28 4F 00 06 00 00 00 .........(O.....
000001F0  40 70 C1 07 14 A7 88 04 C0 C3 57 00 FD FD FD FD @p........W.....
00000200  DD DD DD DD DD DD DD DD 51 00 00 00 41 00 00 00 ........Q...A...
00000210  A0 E4 13 08 40 E2 13 08 00 00 00 00 00 00 00 00 ....@...........
00000220  12 00 00 00 01 00 00 00 34 8E 08 00 FD FD FD FD ........4.......
00000230  77 77 77 2E 65 6E 65 74 73 65 72 76 65 2E 63 6F www.enetserve.co
00000240  6D 00 FD FD FD FD DD DD 41 00 00 00 61 00 00 00 m.......A...a...
00000250  90 E6 13 08 10 E1 13 08 00 00 00 00 00 00 00 00 ................
00000260  2E 00 00 00 01 00 00 00 23 8E 08 00             ........#...    

Comment 6

[Peter Lubczynski]

Attachment: Network Monitor POST frames saved in CAP format????

Comment 7

[Peter Lubczynski]

Darin/Gagan: Can you take a look at this from your end? It looks like an OLD 
problem. Perhaps new changes will fix this.

Comment 8

[av (gone)]

Looks like the same issue that we have with Acrobate forms, bug 53347. The 
problem there is that the form data is stored in a temp file first and then 
NPN_PostURL is called with this file as the data source. But file we get at this 
point is wrong. New cache may have a huge impact on this.

Comment 9

[Peter Lubczynski]

Since this depends on the new cache, it probably won't be done by 0.9

Moving to 1.0

Comment 10

[Darin Fisher]

I don't see how this will be improved by the new cache.  The formpost temp
file is created by layout, and it is not stored in the cache... it is stored
in /tmp.  There shouldn't be any reason why the "file is wrong"...

Eric: do you have any idea why the formpost data file could be getting 
scrubbed/renamed/etc?

Comment 11

[Eric Pollmann]

> The formpost temp file is created by layout, and it is not stored in the
> cache... it is stored in /tmp.  There shouldn't be any reason why the "file is
> wrong"...
>
> Eric: do you have any idea why the formpost data file could be getting
> scrubbed/renamed/etc?

True, but AFAIK, this is only for HTML forms.  I don't think Flash plugin forms
use the form post code in layout.  So... I don't know what is happening with
this testcase.  ???  :S

FWIW, as an unrelated side note, I'm working on changes in HTML form submit to
get rid of that temp file in HTML multipart/form post.  :)

Comment 12

[Darin Fisher]

interesting... then who is creating the POST data stream?

Comment 13

[Eric Pollmann]

lxr says NS_NewPostDataStream appears here:
http://lxr.mozilla.org/seamonkey/ident?i=NS_NewPostDataStream

Specifically, here's the occurance in plugins:
http://lxr.mozilla.org/seamonkey/source/modules/plugin/nglsrc/nsPluginHostImpl.cpp#3926

Comment 14

[Peter Lubczynski]

Could it be the FixPostData() call before or the fact we delete [] the postData 
too soon?

Andrei, do you have some background on this? Do you know if we are using layout 
to do this, specifically (I think) a link handler?

Getting more people on the radar and nominiating nscatfood

Comment 15

[Peter Lubczynski]

*** Bug 60722 has been marked as a duplicate of this bug. ***

Comment 16

[Eric Pollmann]

Dup of bug 53347?  I just posted a patch there you can try!  :)

Comment 17

[Eric Pollmann]

Attachment: patch 1

Comment 18

[Eric Pollmann]

Hmm, they are two different issues - two different API's in plugin land both
implementing form post in different ways.  Patch 1 fixes the two pages on this
report.

Comment 19

[Peter Lubczynski]

Eric,

Your patch works great, I think it should go in ASAP. I can check it in or you 
get r= peterl but why not initilize postDataStream and headerDataStream to 
nsnull?

Bug 53347 should be fixed in a similar way.

Shrirang attached testcase is a good one to try:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=28913
But be wery of the backspace key as it "Goes Back".

Marc, can you sr= this pach?

Comment 20

[Marc Attinasi]

Peter, no need to initialize nsCOMPtr's to nsnull - they are by default, and the
initialization just results in an extra finction call (or more likely, 20 extra
function calls).

sr=attinasi on the patch, it looks good. What is being done about the reported
fact that this is being done two different ways in plugins? 

Comment 21

[Peter Lubczynski]

Bug 74457 was opened on refactoring code from nsObjectFrame.cpp and 
nsPluginViewer.cpp.

This is yet another case. When all the plugin fires die down, this should be 
done.

Comment 22

[Peter Lubczynski]

Patch checked in, marking FIXED.

/cvsroot/mozilla/layout/html/base/src/nsObjectFrame.cpp,v  <--  
nsObjectFrame.cpp
new revision: 1.208; previous revision: 1.207

Comment 23

[shrirang khanzode]

created username: test1 password :qatest1 and was able to logon to this site. 
Verified on windows, mac ,linux trunk builds 04/12.