[Laszlo-dev] [Laszlo-user] FW: Response Header problem in lps3.2
Jim Grandy
jgrandy at openlaszlo.org
Mon Jun 5 00:51:11 EDT 2006
That change came too late for 3.2, and was not integrated into 3.3.
Once we have 3.3.1 released, please integrate the change from lps-dev
into lps-3.3, and annotate the bug accordingly.
jim
On Jun 4, 2006, at 7:02 PM, Henry Minsky wrote:
> I made a fix, changeset 40979 on 2006/03/29 which fix the set-header
> behavior. I am wondering now if that made it into the 3.2 (or 3.3)
> releases.
>
> Jake, can you tell me the value that prints out in the debugger if you
> type
>
> LzLoadQueue.qargs ?
>
> It should be this list. If "headers" is missing ,that is the bug,
> you can add this code as a patch.
>
>
> LzLoadQueue.qargs = [ 'nsprefix',
> 'trimwhitespace',
> 'sendheaders',
> 'headers',
> 'reqtype',
> 'timeout',
> 'fpv',
> 'ccache'];
>
>
>
> On 6/4/06, Henry Minsky <henry.minsky at gmail.com> wrote:
> I'm testing in the top-of-tree of our dev branch, it's possible
> that a fix
> for set-headers went in to my branch but wasn't taken in the last
> release.
>
> I wonder if a nightly build would have the same behavior as I am
> getting now?
>
>
>
> On 6/4/06, jake yang < yang_dx at 163.com> wrote:
> That's weird. Look at my screenshot. I have different result from
> you. Are you using lps 3.2 or lps 3.3?
>
> Maybe there is something wrong in my environment, I will look into it.
>
> Thanks
>
>
>
> From: Henry Minsky [mailto:henry.minsky at gmail.com]
> Sent: 2006年 6月5 日 3:47
>
>
> To: jake yang
> Cc: laszlo-user at openlaszlo.org
> Subject: Re: Re: [Laszlo-user] FW: Response Header problem in lps3.2
>
>
> How are you testing whether the header is set? You test returns
> this for me:
>
> Header: JSESSIONID=AF276EDE8A72609E88E9D59989957CDD; Path=/
> SimpleServlet
> dataset: «LzDataset#0|
> <dsTest><sessionid>AF276EDE8A72609E88E9D59989957CDD</sessionid></
> dsTest>»
>
> Session id correct: JSESSIONID=AF276EDE8A72609E88E9D59989957CDD;
> Path=/SimpleServlet
> dataset: «LzDataset#1| <dsTest1><HasSession>session
> id=AF276EDE8A72609E88E9D59989957CDD</HasSession></dsTest1>»
>
>
> And there is a regression test in test/lfc/data/alldata called
> testsetheaders.lzx which sets the content type and that appears to
> be working.
>
>
>
> On 6/4/06, jake yang < yang_dx at 163.com> wrote:
>
> Hi
>
> Thanks for your patch, and I did test it. There seems to be a
> little problem. I can get the header information in the test.lzx
> now (when click the first button), but still can not set it.
>
> When the second request goes to the test servlet, it can't get the
> Session before.
>
> Hope you can fix it. Thanks
>
>
> Jake Yang
>
> From: Henry Minsky [mailto:henry.minsky at gmail.com]
> Sent: 2006年 6月4 日 22:06
>
>
> To: jake yang
> Cc: laszlo-user at openlaszlo.org
>
> Subject: [Norton AntiSpam] Re: [Laszlo-user] FW: Response Header
> problem in lps3.2
>
>
> Sorry, I sent the old code, here's the new code
>
> <script>
> <![CDATA[
> LzLoader.prototype.returnData = function ( loadobj , data ){
> // Check if returnData has already been called on this
> // object. This can happen if a serverless data load timed out in
> // the LFC, but eventually returned something via the
> // LoadVars.sendAndLoad() callback.
> if (loadobj.loaded) {
> if ($debug) {
> Debug.warn("%w.returnData: %w already loaded",
> this, loadobj);
> }
> return;
> }
>
> if (loadobj instanceof MovieClip) {
> // Nothing to do
> } else if (loadobj instanceof XMLNode) {
>
> // Do a fixup to add one extra level of data node to the data,
> // to be compatible with what the DataCompiler produces.
> var ndata = new LzDataElement('resultset');
>
> // The raw XML response string was stashed here by
> LzLoadQueue.serverlessOnDataHandler
> // TODO [2005-08-11 ptw] Is there not an issue that there
> // could be multiple requests?
> if (this['rawtext']) {
> ndata.rawtext = this.rawtext;
> }
>
> if (typeof(data) != 'undefined') {
> if (loadobj.proxied) {
> // proxied req gets back <resultset><body>XML</
> body><headers/></resultset>
> ndata.setChildNodes(data.childNodes[0].childNodes);
> } else {
> // SOLO, we get back raw XML only
> ndata.setChildNodes([data]);
> }
> }
>
> data = ndata;
> } else {
> if ($debug) {
> Debug.error("%w.returnData: unhandled loadobj %w",
> this, loadobj);
> }
> }
>
> // Ok, we have loaded this. loadFinished changes state of loadobj
> // from loading to loaded.
>
> // TODO [2005-08-11 ptw] If this were a multi-threaded system, we
> // would have to worry about getLoadMovie trying to reuse the
> // loadobj before we have finished with it.
>
> // [2005-08-25 ptw] So, we don't want to mark the clip as loaded
> // if this is a persistent connection? Not sure what that means.
> if ( ! this.doPersist ) _root.LzLoadQueue.loadFinished( loadobj );
>
> // [2005-08-25 ptw] Is this correct? Do we really want an aborted
> // request to signal that it timed out?
> if ( ! loadobj.valid ) {
> this.doTimeOut(loadobj);
> return;
> }
>
> this.lastloadtime = getTimer() - loadobj.loadtime;
>
> var err;
> if ( data.childNodes[0].nodeName == "error") {
> err = data.childNodes[0].attributes.msg;
> } else if (data.nodeName == "error") {
> err = data.attributes.msg;
> } else if (data == "medialoaderror") {
> err="Media load error";
> }
>
> if ( err != null ){
> Debug.error( err );
> this.onerror.sendEvent( data );
> return;
> }
>
> if ( this.queuing ){
> loadobj.data = data;
>
> while ( this.expectedList.length &&
> this.expectedList[ 0 ].loaded ){
> var tlmc = this.expectedList.shift();
> if ( tlmc.timedout ){
> this.doTimeOut(tlmc);
> } else if( tlmc.data ){
> this.ondata.sendEvent( tlmc.data );
> tlmc.data = null;
> }
> }
> } else {
> if ( loadobj.timedout ){
> this.doTimeOut(loadobj);
> } else if( data ){
> this.ondata.sendEvent( data );
> }
> }
> }
>
> ]]>
> </script>
>
> On 6/4/06, Henry Minsky < henry.minsky at gmail.com> wrote:
>
> Below is a patch to the LFC for the moment that you could place at
> the start of your application.
>
> I am not sure when this will make the next nightly build. In fact,
> if you can test my
> patch that would be great.
>
> Place these two functions at the start of your app in a script
> block, or include them in a library containing the script.
>
> <script>
> <![CDATA[
> LzLoader.prototype.returnData = function ( loadobj , data ){
> // Check if returnData has already been called on this
> // object. This can happen if a serverless data load timed out in
> // the LFC, but eventually returned something via the
> // LoadVars.sendAndLoad () callback.
> if (loadobj.loaded) {
> if ($debug) {
> Debug.warn("%w.returnData: %w already loaded",
> this, loadobj);
> }
> return;
> }
>
> if (loadobj instanceof MovieClip) {
> // Nothing to do
> } else if (loadobj instanceof XMLNode) {
>
> // Do a fixup to add one extra level of data node to the data,
> // to be compatible with what the DataCompiler produces.
> var ndata = new LzDataElement('resultset');
>
> // The raw XML response string was stashed here by
> LzLoadQueue.serverlessOnDataHandler
> // TODO [2005-08-11 ptw] Is there not an issue that there
> // could be multiple requests?
> if (this['rawtext']) {
> ndata.rawtext = this.rawtext;
> }
>
> if (typeof(data) != 'undefined') {
> if (loadobj.proxied) {
> // proxied req gets back <resultset><body>XML</
> body><headers/></resultset>
> ndata.setChildNodes([data.childNodes[0].childNodes
> [0]]);
> } else {
> // SOLO, we get back raw XML only
> ndata.setChildNodes([data]);
> }
> }
>
> data = ndata;
> } else {
> if ($debug) {
> Debug.error ("%w.returnData: unhandled loadobj %w",
> this, loadobj);
> }
> }
>
> // Ok, we have loaded this. loadFinished changes state of loadobj
> // from loading to loaded.
>
> // TODO [2005-08-11 ptw] If this were a multi-threaded system, we
> // would have to worry about getLoadMovie trying to reuse the
> // loadobj before we have finished with it.
>
> // [2005-08-25 ptw] So, we don't want to mark the clip as loaded
> // if this is a persistent connection? Not sure what that means.
> if ( ! this.doPersist ) LzLoadQueue.loadFinished( loadobj );
>
> // [2005-08-25 ptw] Is this correct? Do we really want an aborted
> // request to signal that it timed out?
> if ( ! loadobj.valid ) {
> this.doTimeOut(loadobj);
> return;
> }
>
> this.lastloadtime = getTimer() - loadobj.loadtime;
>
> var err;
> if ( data.childNodes[0].nodeName == "error") {
> err = data.childNodes[0].attributes.msg;
> } else if (data.nodeName == "error") {
> err = data.attributes.msg;
> } else if (data == "medialoaderror") {
> err="Media load error";
> }
>
> if ( err != null ){
> Debug.error( err );
> this.onerror.sendEvent( data );
> return;
> }
>
> if ( this.queuing ){
> loadobj.data = data;
>
> while ( this.expectedList.length &&
> this.expectedList[ 0 ].loaded ){
> var tlmc = this.expectedList.shift();
> if ( tlmc.timedout ){
> this.doTimeOut(tlmc);
> } else if( tlmc.data ){
> this.ondata.sendEvent( tlmc.data );
> tlmc.data = null;
> }
> }
> } else {
> if ( loadobj.timedout ){
> this.doTimeOut(loadobj);
> } else if( data ){
> this.ondata.sendEvent( data );
> }
> }
> }
>
> ]]>
> </script>
>
>
>
> On 6/3/06, jake yang < yang_dx at 163.com> wrote:
>
> Hi,
>
> Thanks for your kindly help. Is it possible to fix it in the next
> nightly building?
>
> Can we have a quick workaround by just add something in our lzx
> file? If not, we have to wait until this bug has been fixed in the
> future building.
>
>
> Jake Yang
>
> From: Henry Minsky [mailto:henry.minsky at gmail.com]
> Sent: 2006年 6月4 日 4:04
>
>
> To: jake yang; Jim Grandy
> Cc: Laszlo
>
>
> Subject: Re: [Laszlo-user] FW: Response Header problem in lps3.2
>
>
> I found the problem. It is a regression, it happened when we
> switched from
> using server-side SWF-encoded data to using the Flash parser on the
> client side, the header data was getting discarded.
>
> I have a fix, not sure what the best way to get this out to the
> community is.
>
> On 6/3/06, Henry Minsky < henry.minsky at gmail.com> wrote:
>
> OK I can reproduce the error you're seeing (I had to recompile the
> servlet classes on my machine for some reason).
>
> I'm taking a look at this now.
>
> On 6/3/06, jake yang < yang_dx at 163.com> wrote:
>
> Hi Henry,
>
> Thanks for your reply. Testcase.zip is the test case you want.
>
> I test it in lps3.1 and lps3.2 with Java 1.5, and I have the
> screenshot in the zip file which shows the different result.
>
>
> Put the test.lzx in the Server\lps-3.2\my-apps, and the
> "SimpleServlet" folder in the Server\tomcat-5.0.24\webapps,
>
> Then run the test.lzx with the debug option.
>
>
> Contact me if you have any problem of running this test case. Thanks
>
>
> Jake Yang
>
>
> From: Henry Minsky [mailto:henry.minsky at gmail.com]
> Sent: 2006年 6月3 日 14:36
>
>
> To: jake yang
> Cc: laszlo-user at openlaszlo.org
> Subject: Re: [Laszlo-user] FW: Response Header problem in lps3.2
>
>
> Can you send a zip file with a test case with running code for me
> to try?
>
> On 6/2/06, jake yang < yang_dx at 163.com > wrote:
>
> Isn't anyone who met the same session problem? How to keep the lps
> dataset request with the same sessionid which is needed by the
> tomcat java server?
>
> getResponseHeader("Set-Cookie");
>
> setHeader("Cookie",SessionID);
>
> these two method did work in lps3.1, but when I use lps3.2, they
> seem not work at all.
>
> Pls, help me.
>
> Thanks!
>
>
> From: laszlo-user-bounces at openlaszlo.org [mailto: laszlo-user-
> bounces at openlaszlo.org] On Behalf Of jake yang
> Sent: 2006年 6月2 日 18:08
> To: laszlo-user at openlaszlo.org
> Subject: [Laszlo-user] Response Header problem in lps3.2
>
>
> Hi
>
> The code below works in lps3.1, but it doesn't works in lps3.2 and
> lps3.3
>
> dataset.getResponseHeader("Set-Cookie");
>
> setHeader("Cookie",SessionID);
>
>
> what should I do if I want to get the same thing in lps3.2 and 3.3?
>
>
> _______________________________________________
> Laszlo-user mailing list
> Laszlo-user at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-user
>
>
>
>
>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com
>
>
>
>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com
>
>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com
>
>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com
>
>
>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com
>
>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com
>
>
>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com
>
>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20060605/2924e625/attachment-0001.html
More information about the Laszlo-dev
mailing list