One thing I am thinking as I look at the code is that the 'setQueryString' method is very confusing right now, since it really doesn't directly set the query string. It is really just acting as a synonym for setQueryParam[s], which manipulates this 'params' table of key value pairs.
Maybe we should make setQueryString actually overwrite the src URL query string. I think that would be more along the lines of what people expect, and actually fits our existing documentation more closely. Then setQueryParam[s] would be the only official way to manipulate the 'params' table, and the params data will either be www-form-encoded as the body of POST requests, or merged in with the query string for GET requests. If there are query string args that shadow params table args, it is undefined which one has priority. Or we could make a rule that the params table entries get priority. Note, we are still limited by Flash 8 to having no duplicate query args in a SOLO GET request. So setQueryString would have slightly different behavior than what we have now, although for GET requests, it would actually be more like the pre-4.x behavior. For POST requests though, the query string set by setQueryString would really show up in the URL, and the params would show up in the post body. On Jan 21, 2008 8:18 PM, P T Withington <[EMAIL PROTECTED]> wrote: > What I was imaginging was in dataprovider API, you get: > > + URL (as an LzURL, which may have a non-null query component) > + queryparams (which may have been set with setQueryString or > setQueryParams on the dataset, but not via setSrc) > > At that API, the query component of the URL and the queryparams object > have no relation to each other. There should be no need for > querystring, since it should be the same as queryparams. The URL > should come as an LzURL because, as I noted, you ought to be able to > have a #fragment component of the URL that gets passed on too. If you > send it as a string, you will just have to re-parse it anyways (at > least for the HTTP/GET case). > > It should be only in the HTTP/GET transport that the queryparams are > squeezed into the query component of the URL. For any other protocol, > and for HTTP/POST, the queryparams are sent along a 'control > channel' (the POST body, for instance). > > > On 2008-01-21, at 20:00 EST, Henry Minsky wrote: > > > I'm looking at how we can preserve the query string so it can remain > > attached to the URL when making a POST request. > > > > This requires some hacking at several levels, because while we can > > (and do) > > keep the query string and query params separate in the LzDataset, > > we're mushing them together into a single url in LZHTTPDataProvider, > > and all > > the levels below that expect a single URL with all the data in it. > > Unfortunately that extends to the proxy server as well, it expects > > to see a > > single query string. > > > > The reason we're in trouble here is that a decision early on was > > made to > > try to abstract data transport away from > > HTTP and URLs, etc, and just treat it as key-value pairs, and that > > has come > > back to bite us. > > > > It extends to our protocol for proxy requests; the protocol we have > > with the > > server is to expect a single URL containing all data and query args > > mixed > > together. > > > > We should probably change the protocol we're using for proxy data > > requests, > > to explicitly pass the data params > > separately from the URL. We might be able to get away with reusing > > the magic > > "lzpostbody" arg as we do now, but making the > > policy that the client does not have to send that as the *only > > *query arg. > > The client can instead send the URL with querystring > > and the server will pluck out the lzpostbody arg if there is one, > > and use it > > for the post body, while keeping the rest > > of the args as the query string. > > > > For SOLO requests, we can also use the lzpostbody for the query > > params; > > internally in the LFC, the code path for > > raw SOLO posts actually keeps the raw post data in a separate var > > all the > > way down to where the HTTP request is sent, > > so we can stick the query params data as a URL-encoded query string > > in > > there. > > > > I'm going to try making a patch to do this, for wafflecone. I don't > > know if > > it's worth trying to make a back compatibility flag for > > this now, or just say that we're changing the things work again; > > people were > > getting unexpected results when we > > changed things for 4.x to have setQueryString null out the query > > params and > > vice versa, so maybe just backing out > > of that behavior is best. Introducing this new behavior which keeps > > the > > query string args confined to the URL even > > in POST requests seems like a more HTTP/HTML compatible API, > > considering > > that XMLHTTPRequest behaves that way; > > In XMLHTTPRequest, you open a request to a URL, which can have query > > string, > > and then you call send(data) with > > any POST data you want to stuff in the request body. I feel like we > > ought > > to be trying to emulate that model, I don't see > > the point in trying to abstract away from it, we've just caused > > trouble by > > doing so, so far. > > > > > > > > > > > > > > > > > > -- > > Henry Minsky > > Software Architect > > [EMAIL PROTECTED] > > -- Henry Minsky Software Architect [EMAIL PROTECTED]
