2

I am building an HTML5 single page app, and I want to allow the user to keep the current application state for later use. I want to achieve this by creating a link URL to my page, with a specially crafted query part. When called again, with the URL, the application would parse the query part and recreate the stored state.

Now, some part of the state is a list, whose items are numerical values and an associated text. The floating-point numerical values, as well as the text is not required to be unique.

Like this:

4.54  first
12.1  another
12.1  more
34    more

My intent is to create an URL like so:

www.myappdomain.com/SinglePage.html?4.54=first&12.1=another&12.1=more&34=more

Is this a legal URL? Given proper encoding of the text, will this work in the wild?

I have read What Every Developer Should Know About URLs by Alan Skorkin, which I can generally recommend about URLs and this Answer about URL character usage.

To me, doing it that way seems legal but I still feel a little uncomfortable, since I have not found information about the possibly non-unique keys I might have and about numbers as keys in query parts in general.

Edit: I've brought it to work, see below (tell me if link ever breaks): http://quir.li/player.html?media=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D0VqTwnAuHws&title=What%20makes%20you%20beautiful&artist=The%20piano%20guys%20covering%20One%20Republic&album=Youtube&6.49=Intro&30.12=Knocking%20part&46.02=Real%20playing&51.5=Piano%20forte&93.32=Stringified&123.35=Vocals&139.38=Key%20cover%20jam&150.16=Good%20morning%20sky&173.96=Final%20chord

Community
  • 1
  • 1
Marcel
  • 15,039
  • 20
  • 92
  • 150

3 Answers3

2

This is a legal URL by the URI specification -- https://www.rfc-editor.org/rfc/rfc3986. However, whether this will work in the wild is a different issue since the specification only defines the generic syntax of URIs.

Since there is no specification on what should be done for duplicate keys in the query part (see Authoritative position of duplicate HTTP GET query keys) different software frameworks will treat such URIs differently. However, most frameworks will correctly detect duplicate keys as multiple values with the same key and group such values into a single array/list of values for the given key (rather than using the last value with the given key and discarding all the previous values for that key). Using numbers as keys is also OK since keys are parsed as text strings. In short: you should be safe.

Community
  • 1
  • 1
Ivan Zuzak
  • 18,068
  • 3
  • 69
  • 61
  • Thanks for the rfc link. As far a I read the query part (Section 3.4), the key=value scheme is not even mandatory! – Marcel Sep 17 '12 at 19:32
0

I don't think it a good way to pass data, query string parameters generally regarded as parameters that can be accessed by their name, here you actually pass some data as parameters , while from technical point of view this can be done it makes your code somewhat obfuscated, I would pass this data in a single parameter using JSON encoding

MichaelT
  • 7,574
  • 8
  • 34
  • 47
  • That's the way I'm doing it currently - stringify the list (which technically is an array) and url-encoding it as one large value. However this method creates quite large URLs, and I would like to keep them smaller. – Marcel Sep 17 '12 at 19:36
  • 2
    You can use something like this d=4.54:first,12.1:another,12.1:more,34:more in this way your overhead is just 2 bytes compared to passing this values as params – MichaelT Sep 17 '12 at 19:46
0

This post suggests that there is no spec which says that non-unique keys are invalid.

Authoritative position of duplicate HTTP GET query keys

I can't seem to find anything concrete about number keys.

However, this might be a workaround if you don't want to use non-unique numeric keys for any reason: Use some basic encoding to map numbers to strings. Something basic could be 1-a, 2-b, 3-c, 4-d...9-i, 0-j. And '.' could be 'k' (if there is not spec about whether '.' is a legal character in a URL parameter) Then, e.g., 21.3 would encode to bakc. Also you can add a number in the end of the encoded key to ensure that keys are unique. These numbers would be ignored while decoding (or could help differentiate between the parameters). Then the first 21.3 would encode to bakc1, the next bakc2 etc)

Community
  • 1
  • 1
Himanshu P
  • 9,586
  • 6
  • 37
  • 46
  • This seems quite a lot of work and does not make things more simple as the solution given by MichaelT. – Marcel Sep 17 '12 at 21:48
  • Yup, I upvoted that solution just after posting mine :) Anyway, what I have posted might be useful in some other scenario. – Himanshu P Sep 18 '12 at 07:57