Great article indeed. What I personally missed there was a clear statement about segment (or path) parameters as opposed to query ("search") parameters: //

Great article indeed. What I personally missed there was a clear statement about segment (or path) parameters as opposed to query ("search") parameters: //domain.tld/segment;param1=value1,param2/segment?query=.. Clearly nowadays it seems a bit odd. I bumped into it while reading about this in the "HTTP: The Definitive Guide" from 2002 chapter "2.2 URL Syntax". Actually read this just few years ago and ever since pondered whether this aspect was or was not really adopted by some wild CGI at the times I haven't experienced myself. Definitive guide apparently paraphrased RFC 2396 which clearly defined semicolon as segment parameter delimiter, but later was obsoleted [a] by RFC 3986, moving former standard to "possible practise" [b] stating that: > URI producing applications often use the reserved characters allowed in a segment to delimit scheme-specific or dereference-handler-specific subcomponents. For example, the semicolon (";") and equals ("=") reserved characters are often used to delimit parameters and parameter values applicable to that segment. The comma (",") reserved character is often used for similar purposes. For example, one URI producer might use a segment such as "name;v=1.1" to indicate a reference to version 1.1 of "name", whereas another might use a segment such as "name,1.1" to indicate the same. Parameter types may be defined by scheme-specific semantics, but in most cases the syntax of a parameter is specific to the implementation of the URI's dereferencing algorithm. [c] [a] would't have noticed without: http://stackoverflow.com/questions/6444492/can-any-path-segments-of-a-uri-have-a-query-component http://stackoverflow.com/questions/6444492/can-any-path-segm... [b] https://tools.ietf.org/html/rfc3986#section-3.3 https://tools.ietf.org/html/rfc3986#section-3.3