Makes sense. I like this proposal.
On Tue, 22 Jan 2008, Henry Minsky wrote:
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]
