W3C home > Mailing lists > Public > public-review-announce@w3.org > July 2015

Re: Suggestion for HTTP protocol in URL GET variables

From: timeless <timeless@gmail.com>
Date: Fri, 31 Jul 2015 07:10:59 -0400
Message-ID: <CACsW8eFF3B8EY8XxA9T1OavC7dn5C0jSHdRp0QBPWDng0B4A8w@mail.gmail.com>
To: Joseph Lee <joseph.lee.esl@gmail.com>
Cc: public-review-announce@w3.org
I'm not sure which Ian you're trying to address, but, no, this list isn't
going to work.

The problem with "?" is that it's a perfectly reasonable character for a
user to want to include in a value,


At this point, the way that URLs are handled is unlikely to change, "?"
starts a query, "#" ends the query (because it's the delimiter for the next
field of the URL). Within the query, an individual website is free to do
whatever it likes, but the conventions are:
1. A user agent submitting a form using GET to the server will use "&" to
delimit fields and "=" to identify field values.
2. Because "&" is such a messy character to write in URLs in anchors
(because it's the html escape character), ";" will probably be supported as
a convenience for content authors. This was noted in HTML 4 [1]

If your website doesn't use GET for form posts, you could choose not to
treat "&" as a delimiter and do whatever you like with queries in your URLs.

On Jul 30, 2015 3:28 PM, "Joseph Lee" <joseph.lee.esl@gmail.com> wrote:

> Dear Ian,
> I'm sure you are really busy.  I just had a suggestion and I wondered if
> this was the right place to send it.
> Using GET line variables, the first variable is identified with a '?'
> while subsequent variables are identified with '&'.
> Why not just allow all variables to be identified with '?'.
> Sincerely,
> Joseph
> --
> Joseph Lee
> M.B.A Technology and Innovation Management. - National Chung-Hsing
> University
> B.A. Anthropology - University of Saskatchewan
> Phone: 705-776-1665
> Email: joseph.lee.esl@gmail.com
Received on Friday, 31 July 2015 11:11:28 UTC

This archive was generated by hypermail 2.3.1 : Friday, 31 July 2015 11:11:28 UTC