History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: LPP-2133
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: P2 P2
Assignee: Henry Minsky
Reporter: Henry Minsky
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
OpenLaszlo

response headers dont' show up anymore in datasets

Created: 03/Jun/06 08:16 PM   Updated: 27/Nov/06 08:59 AM
Component/s: LFC - Data
Affects Version/s: 3.3
Fix Version/s: 3.4, 3.3.3

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive testcase.zip (58 kb)


Severity: Minor
Fixed in Change#: 2,653
Runtime: N/A
Fix in hand: True


 Description  « Hide
Proxied data loads used to return HTTP server response data, it no longer is being set.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Henry Minsky - 03/Jun/06 08:17 PM
This is a test case from Jake Yang. Note, I had to recompile the java servlet classes to make it load into Tomcat

Henry Minsky - 03/Jun/06 08:18 PM
The LzLoader returnData method got rewritten when we switched to client-parsed data, and was stripping the header data from the server response, for no good reason.

I have a patch pending to fix this.

Henry Minsky - 04/Jun/06 11:03 AM

The patch was in returnData:

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 );
        }
    }
}

Amy Muntz - 05/Jun/06 12:08 PM
Jim - please apply fix (see Henry's comments) in lps-3.3 and merge to svn.

Henry Minsky - 05/Jun/06 12:36 PM
Note, we also need to take changeset listed below:

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'];

Jim Grandy - 07/Jul/06 01:02 PM
Rescheduling for 3.4.

Jim Grandy - 07/Jul/06 01:02 PM
Changeset 40979 is in svn trunk.

Jim Grandy - 07/Jul/06 01:06 PM
Now that this is a 3.4 bug, I'll let Henry integrate his patch into svn openlaszlo/trunk. Assigning to Henry.

Henry Minsky - 27/Nov/06 08:59 AM
I integrated this change and added a test case to test/lfc/data/alldata.lzx