[Laszlo-dev] [Platform-team] proposed changes to support preserving query string in POST requests

[Pablo Kang]

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 <ptw at pobox.com> 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
>>> hminsky at laszlosystems.com
>>
>>
>
>
> -- 
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com
>