W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010


From: timeless <timeless@gmail.com>
Date: Sun, 10 Oct 2010 18:52:07 +0300
Message-ID: <AANLkTi=pG43zEBCjnk=70g+ZQKTwmxBxD_JPENFgdm2B@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: WebApps WG <public-webapps@w3.org>
On Mon, Sep 20, 2010 at 9:27 AM, Adam Barth <w3c@adambarth.com> wrote:
> On Sun, Sep 19, 2010 at 10:48 PM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote:
>>> 1) There are now two methods for getting at the URL parameters.  The
>> and none for setting them?
> That's correct.  Looking at various libraries, there seems to be much
> more interested in paring out query parameters than for constructing
> them.  One popular JavaScript library did have an API that took a
> dictionary and built a query string out of it.  I imagine most folks
> just use the HTML Form element.

MXR (hg.mozilla.org/webtools/mxr/) has an api for constructing urls
(mostly parameters really). It tends to do redirects/rewrites which
send most but not all of a set of parameters to another location.
Another thing it sometimes tries to do is drop empty bits (<input
name=x value="">) from the url. another thing it of course does is
strip out '../' or similar variations.

Note that MXR happens to mostly do its work server side, but there are
bits which would do equivalent work client side, the server/client
side bit is an implementation detail and I'd expect that people not
caring about JS-off browsers would put much more of the code into the
client and use javascript to do these manipulations.

I'm sorry that I don't have time to read the current document. I'll
try to do that once I finish reading my backlog.
Received on Sunday, 10 October 2010 15:52:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC