Hi Derrell, Am 30.01.2007 um 19:03 schrieb [EMAIL PROTECTED]:
>> Removed two limiting if clauses, because attaching Parameters to >> the URL >> used to be perfectly ok, even for POST requests. Unfortunately, >> your changes >> would have broken existing apps that already use such a supported >> "mixed >> mode" POST request. If such a mode is a serious problem for >> certain backends >> as mentioned in bug #17, we need to find a way to support those >> without >> (possibly) breaking existing apps. > > Ok, that's fine. IIRC, someone posted a reference yesterday that > indicated > that sending parameters on a POST was a violation off the spec. (Am I > remembering that correctly?) If that's so, then I believe that the > default > behavior should be to conform to the spec. If it's not prohibited > by the spec > then you are right, there's no reason to limit sending parameters > when the > request is a POST. I'll confirm in the HTTP spec. I know that URL and body parameters are merged in Servlets, so mixing the two looks to be legal (however, I didn't look it up in any HTTP RFCs). >> The existing solution of Parameter (URL) vs. Data (POST content) >> is the real >> problem. We definitely need a better API there. A third >> alternative of >> introducing formFields solely for the IframeTransport simply does >> not seem >> to be sufficient. That's the reason I want to start discussion for >> a better >> solution for the existing Parameter vs. Data stuff. > > Ultimately, it would be nice to have a generic "form" API that allows > generating forms using qooxdoo widgets and having the submission of > the form > data be automated (or at least semi-automated). That's a bit more > of a > project than is required just to fix this bug. :-) Currently, if > one wants to > use XmlHttpTransport, one must provide the data blob to be sent in its > entirety. It shouldn't be hard to change that. As long as no file upload is involved (which isn't possible with XMLHttpRequest anyway), the encoding to use is "application/x-www-form-urlencoded". Basically, the body looks just like the parameters in a GET request: param1=value1¶m2=value2 Even the escaping rules are the same. Maybe we should provide a general API in qx.io.remote.Request that includes methods like "addURIParameter" and "addBodyParameter"? Of course, "addBodyParameter" only makes sense for POST requests, and you can't mix "setData" with calls to "addBodyParameter". This makes such an API a little ugly, but at least you would have the flexibility to handle all the different use cases. Regards, Andreas ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
