[Bug 20148] New: URLQuery interface does not handle query parameter ordering

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20148

            Bug ID: 20148
           Summary: URLQuery interface does not handle query parameter
                    ordering
    Classification: Unclassified
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: URL
          Assignee: mike@w3.org
          Reporter: simon_kaegi@ca.ibm.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, public-webapps@w3.org

For good or bad there exist a number of back-end systems that rely on a
specific ordering of query parameters. The URLQuery abstraction seems to try to
treat the query like a property bag so ordering is lost and multiple value
handling is awkward.

If a "query" abstraction is still seen as desirable an alternate way of looking
at things might be to treat the query as an ordered set of URLQueryParameter(s)

Something like:

interface URLQueryParameter {
  attribute DOMString name; //decoded
  attribute DOMString? value; //decoded
}

interface URLUtils {
  ...
  attribute URLQueryParameter[]? query;
}
---
1) http://localhost/a/path
url.query -> null;
2) http://localhost/a/path?
url.query -> []
3) http://localhost/a/path?a=b&c%20d=e%20f&g=&h&a=newb
url.query ->[
  {name:"a", value:"b"},
  {name:"c d", value:"e f"},
  {name:"g", value=""},
  {name:"h", value=null}, //or possibly value is not present at all
  {name:"a", value="newb"}
]

The idea being that the "query" attribute would be get/set friendly and kept in
synch with "search".

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 29 November 2012 04:24:16 UTC