I always agreed that it is a bug. I offered a work around, change the type to a POST. This should allow your code to work until the bug gets fixed. Changing to a POST should not effect the way your code works but will allow you to do what you are trying to do.

Jim


On Wed, 8 Nov 2006 07:43 +0000 (GMT Standard Time), Hugh Gibson <[EMAIL PROTECTED]> wrote:
Jim,

> I have not verified this, but try and change your type to a POST not
> a GET, this should fix your problem.
> As a GET, the parameters are appended to the URL using a '?" separator
> and since you already have that on the URL then
> all the additional parameters would get ignored by the server.

It *is* a GET. That's when the problem occurs. The code tries to take account of existing parameters on the URL. If there are no existing ones, the separator for new parameters should be a "?"; if there *are* existing parameters the separator should be a "#".

You can see it if you grep the source for "qx.constant.Core.AMPERSAND". The occurrences in .../io/remote/*.js are all code fragments to make this decision. Here's one from IFrameTransport.js, line 144 (reformatted):

  if (vParametersList.length > 0)
    {
    vUrl += (vUrl.indexOf(qx.constant.Core.QUESTIONMARK) >= 0 ?
                 qx.constant.Core.AMPERSAND :
                 qx.constant.Core.QUESTIONMARK )
             + vParametersList.join(qx.constant.Core.AMPERSAND);
    }

and the one that is wrong from XmlHttpTransport.js, line 251:

  if (vParametersList.length > 0) {
    vUrl += (vUrl.indexOf (qx.constant.Core.QUESTIONMARK) >= 0
             ? qx.constant.Core.AMPERSAND
             : (qx.constant.Core.QUESTIONMARK) +
                vParametersList.join(qx.constant.Core.AMPERSAND));
  }

The bracketing of the conditional operator used to decide this is wrong. It has a lower operator precedence than + so the concatenation of "?" and the parameters is done first, then the decision is made to append "&" or "?<params>". So if you have a URL with existing parameters, and additional parameters are being appended (which can happen if cache is turned off when "nocache" is normally appended) then you just get "&" at the end of the URL.

The bug was introduced with SVN revision 4223 on 14 Sep 2006; the code was correct before then. It appears to have been introduced in some tidying up done by Derrell when applying the patch supplied by Antony Zanetti (you can see it here http://www.nabble.com/Basic-HTTP-authentication-fixes-t2269954.html ). The line of code which was changed is mentioned in the patch but isn't actually changed by it. However, in the SVN revision it *is* changed.

Sorry for spelling it out so clearly - but it's a simple bug, easy to see, easy to fix, and it bit me - so I want it fixed before 0.7 comes out!

Hugh

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to