Here is an example of what we are looking at for 2.0. We'd be happy to
have some comments.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

Looks good and readable.

One comment on:

    BackEnd(not URL("URL_pat") and Header("header_pat")) {
      ...
    }

Maybe it's better to let the BackEnd block have a Condition Sub-Block.
Condition consists of and, not, or, ... subblocks, which internally are
Conditions again.
Through recursion, arbitrary expressions can be formulated.

    BackEnd(
      Condition {
         and {
              not { URL "URL_pat" }
              Condition { Header "header_pat" }
         }
      }
      ...
    }

This is easy to parse, it is very easy to create an internal representation,
and unambiguous.
For simple expressions like to example above it is not so easy to read,
though.
But overall syntax will be cleaner.

Just a suggestion. 

Matthias

> -----Original Message-----
> From: Robert Segall [mailto:roseg(at)apsis.ch] 
> Sent: Wednesday, January 28, 2004 12:57 PM
> To: pound(at)apsis.ch
> Subject: Config grammar - RFC
> 
> 
> Here is an example of what we are looking at for 2.0. We'd be 
> happy to have some comments.

Another note:

From a syntax view only, the following lines are ambiguous:

    ExtendedHTTP                                    # allow extended HTTP
    WebDAV                                          # allow WebDAV

Is WebDAV the parameter value to ExtendedHTTP?
Here, the scanner would need to know that ExtendedHTTP does not have a
parameter value.

Maybe it's better to have a VALUE follow every WORD?

    LogLevel            3                           # 0 to 4
    ExtendedHTTP        yes                         # allow extended HTTP
    SSLEngine           "engine_name"               # hardware crypto
support

Which tool do you use for the scanner/parser?

Regards,
Matthias


> -----Original Message-----
> From: Robert Segall [mailto:roseg(at)apsis.ch] 
> Sent: Wednesday, January 28, 2004 12:57 PM
> To: pound(at)apsis.ch
> Subject: Config grammar - RFC
> 
> 
> Here is an example of what we are looking at for 2.0. We'd be 
> happy to have some comments.

On Wed, 2004-01-28 at 13:29, Matthias Gärtner wrote:
> Another note:
> 
> >From a syntax view only, the following lines are ambiguous:
> 
>     ExtendedHTTP                                    # allow extended HTTP
>     WebDAV                                          # allow WebDAV
> 
> Is WebDAV the parameter value to ExtendedHTTP?

No.

> Here, the scanner would need to know that ExtendedHTTP does not have a
> parameter value.

It knows.

> Maybe it's better to have a VALUE follow every WORD?
> 
>     LogLevel            3                           # 0 to 4
>     ExtendedHTTP        yes                         # allow extended HTTP
>     SSLEngine           "engine_name"               # hardware crypto
> support
> 
> Which tool do you use for the scanner/parser?

bison/yacc are fine - though I'm looking at the possibility of
separating the config parsing and the actual proxy; sort of a config
compiler.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

On Wed, 2004-01-28 at 13:18, Matthias Gärtner wrote:
> Looks good and readable.
> 
> One comment on:
> 
>     BackEnd(not URL("URL_pat") and Header("header_pat")) {
>       ...
>     }
> 
> Maybe it's better to let the BackEnd block have a Condition Sub-Block.
> Condition consists of and, not, or, ... subblocks, which internally are
> Conditions again.
> Through recursion, arbitrary expressions can be formulated.
> 
>     BackEnd(
>       Condition {
>          and {
>               not { URL "URL_pat" }
>               Condition { Header "header_pat" }
>          }
>       }
>       ...
>     }
> 
> This is easy to parse, it is very easy to create an internal representation,
> and unambiguous.
> For simple expressions like to example above it is not so easy to read,
> though.
> But overall syntax will be cleaner.

Logical expressions with precedence are "Parsing 101" - no problem to
parse. I think I would prefer a more understandable syntax, even if it
involves more work (though in this case it doesn't).
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

Hi,

On Mit 28.01.2004 12:57, Robert Segall wrote:
>
>Server {

How about to add a name such as:

Server main {

>    Error500            "path_to_file"              # error 500 file
>    Error501            "path_to_file"              # error 501 file
>    Error503            "path_to_file"              # error 503 file

How about to add an Url for errors such as:

    Error500            "file://path_to_file"        # error 500  file
or
    Error500            "http://..."        # error 500 file

>    BackEnd(not URL("URL_pat") and Header("header_pat")) {
>        Server {

How about to add a name such as:

        Server backend1 {

>        Session URL "id_pat" 300

Do you plan to add the SubCOOKIE possibility?

al ;-)

On Wed, 2004-01-28 at 17:17, Alexander Lazic wrote:
> Hi,
> 
> On Mit 28.01.2004 12:57, Robert Segall wrote:
> >
> >Server {
> 
> How about to add a name such as:
> 
> Server main {
> 
> >    Error500            "path_to_file"              # error 500 file
> >    Error501            "path_to_file"              # error 501 file
> >    Error503            "path_to_file"              # error 503 file
> 
> How about to add an Url for errors such as:
> 
>     Error500            "file://path_to_file"        # error 500  file
> or
>     Error500            "http://..."        # error 500 file
> 
> >    BackEnd(not URL("URL_pat") and Header("header_pat")) {
> >        Server {
> 
> How about to add a name such as:
> 
>         Server backend1 {
> 
> >        Session URL "id_pat" 300
> 
> Do you plan to add the SubCOOKIE possibility?
> 
> al ;-)

1. I'm not clear how you would benefit from named servers. Care to
explain?

2. I avoided the ErrorNNN from anything but a file primarily for
performance reasons (but also code simplicity and security). The file is
read once, on Pound startup, and served as needed. If you need a generic
URL use the Redirect capabilities.

3. I haven't forgotten about the sub-cookie, but I'm not sure how to
define it. Suggestions?
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

On Mit 28.01.2004 17:40, Robert Segall wrote:
>
>1. I'm not clear how you would benefit from named servers. Care to
>explain?

If you have some Servers and backands you can add the $SERVERNAME and
$BACKANDNAME into the errorlog. It makes the debugging easier.

>2. I avoided the ErrorNNN from anything but a file primarily for
>performance reasons (but also code simplicity and security). The file
>is read once, on Pound startup, and served as needed. If you need a
>generic URL use the Redirect capabilities.

Oh yes well.

>3. I haven't forgotten about the sub-cookie, but I'm not sure how to
>define it. Suggestions?

I'm not shure what you mean with 'define' how about:

Session SubCOOKIE "regular_pattern" 300 # cookie pattern for Session

Hth

al ;-)

Looks good to me. Just a couple minor judgment call suggestions:

- Perhaps the "Alive" directive could be something a little less vague?
Maybe AliveCheck, CheckFrequency, etc.

- If SSLEngine will continue to be just for hardware, maybe it'd be
clearer as SSLHardware.


And a few similar nitpicky questions on
HeaderRemove/AddHeaders/ExtraHeader:

- I'm assuming that AddHeaders is for adding headers to the request
being passed to the backend server & ExtraHeader is for adding a header
to the outbound response to the client?

- It seems like AddHeaders and HeaderRemove maybe should be named more
consistently: e.g. either HeaderAdd & HeaderRemove or AddHeader &
RemoveHeader.

- Will they both handle multiple headers similarly - i.e. you can have
multiple HeaderRemove directives currently, will multiple AddHeaders be
supported or are all the headers supposed to be put into a single
AddHeaders directive (because it's obviously not a regexp like
HeaderRemove).

- Also, there's probably a reason for this, but on the surface it seems
somewhat arbitrary that HeaderRemove lives at the "Server" level and
AddHeaders lives that the "HTTPS" level. I suppose in an ideal world,
you could put them both at either level.

Awesome software, by the way!

- Michael

-----Original Message-----
From: Robert Segall [mailto:roseg(at)apsis.ch] 
Sent: Wednesday, January 28, 2004 3:57 AM
To: pound(at)apsis.ch
Subject: Config grammar - RFC

Here is an example of what we are looking at for 2.0. We'd be happy to
have some comments.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

Looks great to me!  One request though - eventually I'd like to automate
pound configuration; it'd be nice if there was some kind of IncludeDir
directive, or an Include with wildcards.  Then I could write specific
configuration files for new SSL cert/ips and restart pound, without
having to touch the main configuration file with a potentially buggy
perl script :)

Sean

> Looks great to me!  One request though - eventually I'd like to automate
> pound configuration; it'd be nice if there was some kind of IncludeDir
> directive, or an Include with wildcards.  Then I could write specific

Nice idea. I'd like to see pound.d/ so we can have something like
/etc/pound.cfg
/etc/pound.d/somehost
/etc/pound.d/otherhosts

Simon

> configuration files for new SSL cert/ips and restart pound, without
> having to touch the main configuration file with a potentially buggy
> perl script :)
>
> Sean
>
>
>

On Wed, 2004-01-28 at 18:40, Alexander Lazic wrote:
> On Mit 28.01.2004 17:40, Robert Segall wrote:
> >
> >1. I'm not clear how you would benefit from named servers. Care to
> >explain?
> 
> If you have some Servers and backands you can add the $SERVERNAME and
> $BACKANDNAME into the errorlog. It makes the debugging easier.

It would be quite complicated to carry that into the logging.

> >3. I haven't forgotten about the sub-cookie, but I'm not sure how to
> >define it. Suggestions?
> 
> I'm not shure what you mean with 'define' how about:
> 
> Session SubCOOKIE "regular_pattern" 300 # cookie pattern for Session

That's how it's defined - but how does it help? You still would need to
indicate the name of the cookie, as well as which is the relevant part
of the content.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

On Thu, 2004-01-29 at 00:35, Michael DeGusta wrote:
> Looks good to me. Just a couple minor judgment call suggestions:
> 
> - Perhaps the "Alive" directive could be something a little less vague?
> Maybe AliveCheck, CheckFrequency, etc.

Fair enough.

> - If SSLEngine will continue to be just for hardware, maybe it'd be
> clearer as SSLHardware.

The crypto hardware support is referred to in the OpenSSL documentation
as "engine". I thought we should keep it consistent.

> And a few similar nitpicky questions on
> HeaderRemove/AddHeaders/ExtraHeader:
> 
> - I'm assuming that AddHeaders is for adding headers to the request
> being passed to the backend server & ExtraHeader is for adding a header
> to the outbound response to the client?

AddHeaders adds SSL-specific headers with the certificate details (name,
dates, etc). ExtraHeader adds a single, user-definable header, to
requests coming in through a specific listener (usually for servers that
need to do certainf things if this is an SSL connection).

> - It seems like AddHeaders and HeaderRemove maybe should be named more
> consistently: e.g. either HeaderAdd & HeaderRemove or AddHeader &
> RemoveHeader.

They don't do quite the same thing, though perhaps RemoveHeader might be
better here.

> - Will they both handle multiple headers similarly - i.e. you can have
> multiple HeaderRemove directives currently, will multiple AddHeaders be
> supported or are all the headers supposed to be put into a single
> AddHeaders directive (because it's obviously not a regexp like
> HeaderRemove).

Both. You can have as many HeaderRemove directives as you wish, and each
can be a regular pattern. I guess we should do the same for AddHeader.

> - Also, there's probably a reason for this, but on the surface it seems
> somewhat arbitrary that HeaderRemove lives at the "Server" level and
> AddHeaders lives that the "HTTPS" level. I suppose in an ideal world,
> you could put them both at either level.

True, but they have different functions. Maybe we should allow
HeaderRemove at the listener level as well...
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

On Don 29.01.2004 08:57, Robert Segall wrote:
>
>It would be quite complicated to carry that into the logging.

Hm why you write the backend and I think it is 'only' a addon value,
isn't it?

>That's how it's defined - but how does it help? You still would need to
>indicate the name of the cookie, as well as which is the relevant part
>of the content.

That might not be necessary because if you have the ability to give a
pattern you search in the whole '(Set-)?Cookie'-line and don't search
only for the name.

e. g.:

Session SubCookie 'JSESSIONID="[0-9a-zA-Z]*!([^!]*)!.*"' 1234

al ;-)

On Thu, 2004-01-29 at 12:52, Alexander Lazic wrote:
> On Don 29.01.2004 08:57, Robert Segall wrote:
> >
> >It would be quite complicated to carry that into the logging.
> 
> Hm why you write the backend and I think it is 'only' a addon value,
> isn't it?

Easier said than done.

> >That's how it's defined - but how does it help? You still would need to
> >indicate the name of the cookie, as well as which is the relevant part
> >of the content.
> 
> That might not be necessary because if you have the ability to give a
> pattern you search in the whole '(Set-)?Cookie'-line and don't search
> only for the name.
> 
> e. g.:
> 
> Session SubCookie 'JSESSIONID="[0-9a-zA-Z]*!([^!]*)!.*"' 1234

I ask again: how does that help? After all we need to track sessions
based on some fixed value - e.g. if the cookie named XYZ has value 123
this connection goes to back-end 1.2.3.4.

Your example perhaps matches the header contents, but how does it tell
Pound which part of the header is important for session tracking and
which not?
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

On Thu, 2004-01-29 at 07:55, Simon Matter wrote:
> > Looks great to me!  One request though - eventually I'd like to automate
> > pound configuration; it'd be nice if there was some kind of IncludeDir
> > directive, or an Include with wildcards.  Then I could write specific
> 
> Nice idea. I'd like to see pound.d/ so we can have something like
> /etc/pound.cfg
> /etc/pound.d/somehost
> /etc/pound.d/otherhosts

OK, I'll look into it.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

Hi,

On Don 29.01.2004 13:52, Robert Segall wrote:
>
>Easier said than done.

Ah ok.

>I ask again: how does that help? After all we need to track sessions
>based on some fixed value - e.g. if the cookie named XYZ has value 123
>this connection goes to back-end 1.2.3.4.

Ah i understand know.

>Your example perhaps matches the header contents, but how does it tell
>Pound which part of the header is important for session tracking and
>which not?

In 'svc.c' 'get_key()':
---
.
.
.
case SessSubCOOKIE:
case SessCOOKIE:
.
.

---

Due the fact that i think we need only _one_ matching '()' we can use
the same way as in normal Cookie matching from 'config.c':

---
snprintf(pat, MAXBUF - 1, "Cookie:.*[ \t]%s=([^;]*)", lin + matches[1].rm_so);
---

I attach my patch to this mail for a example solution.

a ;-)

On Thu, 2004-01-29 at 14:33, Alexander Lazic wrote:
> In 'svc.c' 'get_key()':
> ---
> .
> .
> .
> case SessSubCOOKIE:
> case SessCOOKIE:
> .
> .
> 
> ---
> 
> Due the fact that i think we need only _one_ matching '()' we can use
> the same way as in normal Cookie matching from 'config.c':
> 
> ---
> snprintf(pat, MAXBUF - 1, "Cookie:.*[ \t]%s=([^;]*)", lin +
matches[1].rm_so);
> ---

That assumes that only one part of the cookie is relevant, and fails if
you need a session based on more than that.

I think we should either look at a full sub-pattern mechanism (for
cookies AND URL based sessions) or drop the whole subject. Doing this
sort of thing half-way is probably not a good idea.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

On Don 29.01.2004 16:38, Robert Segall wrote:
>
>That assumes that only one part of the cookie is relevant, and fails if
>you need a session based on more than that.

Thats right.

>I think we should either look at a full sub-pattern mechanism (for
>cookies AND URL based sessions) or drop the whole subject. Doing this
>sort of thing half-way is probably not a good idea.

You are right but this much more time investment, if you want to make it
i have some ideas about this:

1.) Session SubCOOKIE '$REGEX' $TIMEOOUT $MATCHED_PARENTHESES
2.) Session SubCOOKIE '$REGEX' $TIMEOOUT  => and Pound analyse the regex
    and lookup for matching parentheses

al ;-)