[Prev][Next][Index][Thread]
Re: Followup on SEARCH URL's / processing GET forms
Personally, I would like the search args to remain unparsed
and let the user code decide if they want to call the current
faster GET parser lazily or the POST parser. Make these parsers
available for user programming. So I would go one step
backward from what CL-HTTP does.
Examples:
"search?foo+bar" -> ("foo" "bar") <- (("foo" "bar")) <- (("=" ("foo"
"bar")))
"search?foo=1&bar -> ("foo=1" "bar") <- (("foo=" "1") "bar") <- (("foo="
"1") ("=" "bar"))
"search?foo=1+2&bar" -> (("foo=1" "2") "bar") <- (("foo=" ("1" "2"))
"bar") <- (("foo=" ("1" "2")) ("=" "bar"))
"serach?foo+bar&gaz" -> (("foo" "bar") "gaz") <- (("=" ("foo" "bar"))
("=" "gaz"))
If we use a parser with (& + =) precedence we have GET working like
POST for search keys and break existing user code. If we don't, we
need a second pass to disambiguate the current result. We can preserve
the existing parser for GET. Then, if the user code chooses
to it can call a disambiguator function on the URL:SEARCH-KEYS
as a second step.
"search?foo+bar" -> ("foo" "bar") -> (("=" "foo") ("=" "bar"))
"search?foo=1&bar -> ("foo=1&bar") -> (("foo=" "1") ("=" "bar"))
"search?foo=1+2&bar" -> ("foo=1" "2&bar") -> (("foo=" ("1" "2")) ("="
"bar"))
"serach?foo+bar&gaz" -> ("foo" "bar&gaz") -> (("=" ("foo" "bar")) ("="
"gaz"))
Let's name the second step URL:DISAMBIGUATE-SEARCH-KEYS,
someone can post it as a coding exercise in computer.lang.lisp,
and the winner will see her named contribution appear into the official
next code release of CL-HTTP... Right John? [The winning solution
will be a couple of lines long, minimize consing (byte and cons
space) and the number of passes - of course.]
Alternatively the search args remain unparsed... The user code
call a parser of choice.
References: