16 messages in org.apache.james.server-devRe: jSieve parse error with multi-lin...| From | Sent On | Attachments |
|---|---|---|
| Boris Burtin | Jul 1, 2009 2:49 pm | |
| Boris Burtin | Jul 1, 2009 4:59 pm | |
| Robert Burrell Donkin | Jul 2, 2009 7:24 am | |
| Robert Burrell Donkin | Jul 2, 2009 7:42 am | |
| Boris Burtin | Jul 2, 2009 9:50 am | |
| Boris Burtin | Jul 2, 2009 10:17 am | |
| Robert Burrell Donkin | Jul 5, 2009 11:51 pm | |
| Robert Burrell Donkin | Jul 5, 2009 11:54 pm | |
| Boris Burtin | Jul 6, 2009 11:29 am | |
| Robert Burrell Donkin | Jul 6, 2009 11:39 pm | |
| Boris Burtin | Jul 17, 2009 12:11 pm | |
| Robert Burrell Donkin | Jul 23, 2009 2:32 am | |
| Boris Burtin | Jul 23, 2009 12:19 pm | |
| Robert Burrell Donkin | Jul 23, 2009 12:24 pm | |
| Boris Burtin | Jul 27, 2009 1:14 pm | |
| Robert Burrell Donkin | Jul 30, 2009 7:40 am |
| Subject: | Re: jSieve parse error with multi-line form | |
|---|---|---|
| From: | Robert Burrell Donkin (robe...@gmail.com) | |
| Date: | Jul 2, 2009 7:42:03 am | |
| List: | org.apache.james.server-dev | |
On Wed, Jul 1, 2009 at 10:49 PM, Boris Burtin<bbur...@zimbra.com> wrote:
I'm having some trouble with dot-stuffing in a multi-line form. When I try to
parse the script below, I get a syntax exception on the line that starts with
"..":
org.apache.jsieve.parser.generated.TokenMgrError: Lexical error at line 8,
column 1. Encountered: "." (46), after : ""
require ["fileinto", "reject", "tag", "flag"];
# reply filter if anyof (header :contains "subject" "reply") { reply ["use...@cosmonaut.zimbra.com", "use...@cosmonaut.zimbra.com"] "text:" This is the first line This is the second line ..This is a line that begins with a dot And here's a dot by itself: .. The end . ; stop; }
Is my syntax wrong, or did I stumble onto a parsing bug?
at first glance, it looks like a parser bug to me :-/
but i need to spend some more time before i'm sure...
Another issue I ran into is that when parsing doesn't fail, the argument I get
back has the initial CRLF and the trailing ".
CRLF". Seems like the parser should return the unescaped content, instead of
expecting the application code to
handle the unescaping.
i find that this is always a tricky call: a small minority of application may require the raw text but most users want a friendly transparent API to hide these details. certainly, access to the unescaped should be easy for applications. i'm tempted just to provide unescaped text from the current call.
opinions?
- robert