On 08/28/2013 06:04 PM, Alex Rousskov wrote: > On 08/21/2013 09:34 AM, Tsantilas Christos wrote: >> On 08/13/2013 11:57 PM, Alex Rousskov wrote: > >>> Another potential problem here is with the '=' character. We have to >>> allow it because existing code expects it in directive options with >>> values (e.g., bypass=on). However, making '=' a part of the token makes >>> it difficult to support quoted option values: >>> >>> bypass="on" // illegal because a token cannot have quotes >>> >>> "bypass=on" // legal but looks kind of weird >>> // because there are actually several tokens here >>> >>> For simple values such as "on", this is not a problem, but not all >>> option values are that simple, and some of them will require quoting: >>> >>> uri="icap://example.com/?mode=reqmod" // illegal?! >>> >>> "uri=icap://example.com/?mode=reqmod" // weird >>> >>> Changing all callers to treat name=value sequence as three tokens is >>> probably too much work, right? > > >> This is requires changes in many places... > > > I am afraid this problem is serious enough to warrant more discussion > and possibly more work. It feels wrong to insist that folks do > > "foo=bar and baz" > > instead of the natural > > foo="bar and baz" > > and now may be our only chance to add proper support for that.
So we can consider the "=" as a separator char. Probably we can support syntax like the followings: foo="bar and baz" foo= "bar and baz" foo = "bar and baz" > > > What do others think? Is this important enough to fix? > > > If we decide proper support for foo="bar and baz" syntax is important, > the biggest question for me is whether we should > > * change the callers to deal with three tokens (option name, equal sign, > and option value) or > > * change the parser to hide the quotes (producing a single complex token > with "=" inside but without quotes so the callers work as is) Looks that the first is the correct. I am seeing many problems in the second solution. Valid tokens may include "=", for example a url. How we are going to interpret them? > > The former requires more development work but is probably the Right > Thing to Do. > > > Thank you, > > Alex. > >
