diegoles / closure-library

Automatically exported from code.google.com/p/closure-library
0 stars 0 forks source link

iFrameIO reusing form causes incorrect data to be sent on subsequent requests to a uri #409

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago

What steps will reproduce the problem?
1. Do a goog.net.IframeIo.send(url, cb, 'POST', true, data) where data is very 
large, like a png base64 string
2. Do the same request again with a different base64 string
3. The server will continually get the data from the first request.  This does 
not happen when the data is small, only happens on large data (so hard to 
produce a test)

What version of the product are you using? On what operating system?
Latest

Please provide any additional information below.
Simple fix attached

Original issue reported on code.google.com by guido.tapia@gmail.com on 4 Jan 2012 at 1:14

Attachments:

GoogleCodeExporter commented 8 years ago
i'm confused about how this patch works; it seems redundant to me.

As far as I can tell, send() only runs if this.active_ == false. But all the 
places that set active_ to false also call makeReady_ -> disposeForm_, which 
should remove the children. So it's unclear to me how you're getting into this 
state.

Any chance you have a demo somewhere on-hand?

Original comment by Nicholas.J.Santos on 5 Jan 2012 at 1:47

GoogleCodeExporter commented 8 years ago
Hi Nicholas,

Apologies for the delay, I was sure I'd responded to this.  I just ran into 
this again hence checking.  My scenario is a little specific but basically I am 
using the ASP.Net framework to stream a file to the browser.  When streaming a 
file to the browser the response is unceremoniously closed (I don't think this 
is ASP.Net specific).  So with the stream closed like this the IFrameIO does 
not receive a reply and hence it does not dispose correctly. (Note the request 
actually works).

I think this only happens when the request data is quite large.  I'll see if I 
can put up a demo somewhere.

Original comment by guido.tapia@gmail.com on 19 Mar 2012 at 2:53