Re^2: Compare URIs

To be more clear, one should not assume that the order or uniqueness of CGI parameters is arbitrary. Changing the order or enforcing the uniqueness may break some web applications. CGI itself has no rules about parameter ordering or uniqueness. Your application may add such rules or assumptions, but that's up to you.

--
[ e d @ h a l l e y . c c ]

Comment on Re^2: Compare URIs

Replies are listed 'Best First'.
Re^3: Compare URIs by ikegami (Patriarch) on Oct 18, 2005 at 16:16 UTC
~~I have read (in some spec, long ago) that web browsers may return fields in any order, which means the order of the CGI parameters is arbitrary. I can't find where I saw this, though.~~ Update: If what I said was once the case, it is no longer. Quoting HTML docs (emphasis is mine): The control names/values are listed in the order they appear in the document. The name is separated from the value by `=' and name/value pairs are separated from each other by `&'. So halley is correct. HTTP clients and HTTP proxies should consider `...?joe=1&jack=2` and `...?jack=2&joe=1` to be different. (HTTP servers can do whatever they want, of course.)	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Compare URIs
by ikegami (Patriarch) on Oct 18, 2005 at 16:16 UTC

~~I have read (in some spec, long ago) that web browsers may return fields in any order, which means the order of the CGI parameters *is* arbitrary. I can't find where I saw this, though.~~

Update:

If what I said was once the case, it is no longer. Quoting HTML docs (emphasis is mine):

The control names/values are listed in the order they appear in the document. The name is separated from the value by `=' and name/value pairs are separated from each other by `&'.

So halley is correct. HTTP clients and HTTP proxies should consider ...?joe=1&jack=2 and ...?jack=2&joe=1 to be different. (HTTP servers can do whatever they want, of course.)

[reply]
[d/l]
[select]