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

[P T Withington]

I'm not sure _what_ the pre-4.x behaviour was.  I know it was  
confusing and the source of many bugs.  I think the best we could tell  
was that the intent was that both API's manipulate the same thing,  
although the implementation was perfect.

I _don't_ think you should make setQueryString touch the URL.  If  
people want to manipulate the URL they should use the LzURL interface  
to do so.  The query interface should be for manipulating the query  
that the dataset is going to make.  It seems klunky to me to have the  
setQueryString API, but I don't think you can change its contract.   
The most we could do is deprecate it, because it is too implementation- 
specific -- it makes it seem like the dataprovider has to be HTTP.

On 2008-01-22, at 14:56 EST, 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