Is a url query parameter valid if it has no value?

Solution 1:

• Valid to the URI RFC
• Likely acceptable to your server-side framework/code

The URI RFC doesn't mandate a format for the query string. Although it is recognized that the query string will often carry name-value pairs, it is not required to (e.g. it will often contain another URI).

3.4. Query

The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any). ...

... However, as query components are often used to carry identifying information in the form of "key=value" pairs and one frequently used value is a reference to another URI, ...

HTML establishes that a form submitted via HTTP GET should encode the form values as name-value pairs in the form "?key1=value1&key2=value2..." (properly encoded). Parsing of the query string is up to the server-side code (e.g. Java servlet engine).

You don't identify what server-side framework you use, if any, but it is possible that your server-side framework may assume the query string will always be in name-value pairs and it may choke on a query string that is not in that format (e.g. ?bar). If its your own custom code parsing the query string, you simply have to ensure you handle that query string format. If its a framework, you'll need to consult your documentation or simply test it to see how it is handled.

Solution 2:

They're perfectly valid. You could consider them to be the equivalent of the big muscled guy standing silently behind the mob messenger. The guy doesn't have a name and doesn't speak, but his mere presence conveys information.

Solution 3:

"The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax and semantics for http URLs." http://www.w3.org/Protocols/rfc2616/rfc2616.html

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] 

So yes, anything is valid after a question mark. Your server may interpret differently, but anecdotally, you can see some languages treat that as a boolean value which is true if listed.

Solution 4:

Yes, it is valid.

If one simply want to check if the parameter exists or not, this is one way to do so.

Solution 5:

URI Spec

The only relevant part of the URI spec is to know everything between the first ? and the first # fits the spec's definition of a query. It can include any characters such as [:/.?]. This means that a query string such as ?bar, or ?ten+green+apples is valid.

Find the RFC 3986 here

HTML Spec

isindex is not meaningfully HTML5.

It's provided deprecated for use as the first element in a form only, and submits without a name.

If the entry's name is "isindex", its type is "text", and this is the first entry in the form data set, then append the value to result and skip the rest of the substeps for this entry, moving on to the next entry, if any, or the next step in the overall algorithm otherwise.

The isindex flag is for legacy use only. Forms in conforming HTML documents will not generate payloads that need to be decoded with this flag set.

The last time isindex was supported was HTML3. It's use in HTML5 is to provide easier backwards compatibility.

Support in libraries

Support in libraries for this format of URI varies however some libraries do provide legacy support to ease use of isindex.

Perl URI.pm (special support)

Some libraries like Perl's URI provide methods of parsing these kind of structures

$uri->query_keywords
$uri->query_keywords( $keywords, ... )
$uri->query_keywords( \@keywords )
Sets and returns query components that use the keywords separated by "+" format.

Node.js url (no special support)

As another far more frequent example, node.js takes the normal route and eases parsing as either

• A string
• or, an object of keys and values (using parseQueryString)

Most other URI-parsing APIs following something similar to this.

• PHP parse_url, follows as similar implementation but only returns the string for the query. Parsing into an object of k=>v requires parse_string()