On 09/26/2013 10:02 AM, Amos Jeffries wrote: > Last I saw on the new strict configuration issues was that Alex was > requesting final resolution of the squid.conf syntax for regex pattern > tokens in strict parse mode before it goes to 3.4.
I did not request that the RE resolution is made before the code goes into v3.4. IIRC, the committed changes essentially disable RE support in strict mode. That should not introduce backward compatibility problems AFAICT. What I did consider important is that the "foo=bar" decision is made before the committed changes go into v3.4. Here is a quote from my 2013/08/28 email (I assume that is the email you refer to above): >> As I wrote earlier, the 'foo="bar and baz"' issue worries me, but I >> think we can discuss that after your commit. The important part is for >> Amos not to pull your changes into v3.4 until that discussion is over. The reason I wanted us to reach a decision is to avoid telling v3.4 users that the syntax has changed yet again. However, very few users are going to start using the bad "foo=bar and baz" instead of the natural foo="bar and baz" syntax so we can probably go ahead with the pull if needed. > That objection is > essentially blocking 3.4.0.2 release which requires several of the other > fixes in the patch. There are other reasons to worry about that parsing change, but I do not think RE support is holding us hostage here. I hope the above clarifies. As for "other reasons", see below and my next email. > Christos, Do you have any unseen progress on that last remaining piece > of the new parser? Christos has made a lot of parsing improvements since the last commit. However, I think we need to re-evaluate our overall approach to this problem. I told Christos as much yesterday, but he did not have a chance to respond yet. I will forward my email to him here although it is a bit rough. Christos, if you are reading this, please feel free to comment here instead of responding to my private email. > IMO; > I have kind of been favouring regex( some (pattern) ) since we have > now added function(...) style to squid.conf for parameters(things). Note > that brackets can be easily counted to skip the patterns internal ( and > ) groupings and \( \) literals, leaving an easily identifiable > terminator character for regex(...)some_garbage_token . I share the "regex" prefix direction (see my next email) but since parenthesis are used extensively in REs, I do not think they are a good default. It would be very difficult for admins to understand correctly which parenthesis they need to escape inside the RE and how. > I am objecting to the suggested use of // on grounds that it is too > easily confused with perl regex s/pattern/g syntax and if admin start > entering patterns from that regex language syntax into squid.conf > GNU-regex parser undefined problems will arise in ways hard to debug. > However we can always add preg(/pattern/) in future when we add support > for that expression type. > > What say you? AFAIK, the /re/ syntax is used by sed, PHP, Javascript, Ruby, and probably many other tools and languages. It is not specific to Perl and predates Perl. The /re/ syntax tells admins that they are looking at some RE, not that they are looking at a Perl (or any other specific flavor of) RE. The only real problem with /re/ syntax as the default is that it does not work well with URLs, which are very common in Squid patterns. That is why I think a string-based "re" may be a better default for Squid. However, it is not urgent to decide this now if my understanding about RE support in the committed code is correct. The concerns I will highlight in my next email are far more important because they affect strict syntax adoption and a lot of code (so if you pull the committed changes into v3.4 now, we may end up with three rather different code bases to work with: old, v3.4, and trunk). Cheers, Alex.
