Here is an example of what we are looking at for 2.0. We'd be happy to
have some comments.[...]

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
[...]

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

[...]

On Wed, 2004-01-28 at 13:29, Matthias Gärtner wrote:[...]

No.
[...]

It knows.
[...]

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.[...]

On Wed, 2004-01-28 at 13:18, Matthias Gärtner wrote:[...]

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).[...]

Hi,

On Mit 28.01.2004 12:57, Robert Segall wrote:[...]

How about to add a name such as:

Server main {
[...]

How about to add an Url for errors such as:

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

How about to add a name such as:

        Server backend1 {
[...]

Do you plan to add the SubCOOKIE possibility?

al ;-)

On Wed, 2004-01-28 at 17:17, Alexander Lazic wrote:[...]

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?[...]

On Mit 28.01.2004 17:40, Robert Segall wrote:[...]

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

Oh yes well.
[...]

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.[...]

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[...]

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
[...]

On Wed, 2004-01-28 at 18:40, Alexander Lazic wrote:[...]

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

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.[...]

On Thu, 2004-01-29 at 00:35, Michael DeGusta wrote:[...]

Fair enough.
[...]

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

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).
[...]

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

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.
[...]

True, but they have different functions. Maybe we should allow
HeaderRemove at the listener level as well...[...]

On Don 29.01.2004 08:57, Robert Segall wrote:[...]

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

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:[...]

Easier said than done.
[...]

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?[...]

On Thu, 2004-01-29 at 07:55, Simon Matter wrote:[...]

OK, I'll look into it.[...]

Hi,

On Don 29.01.2004 13:52, Robert Segall wrote:[...]

Ah ok.
[...]

Ah i understand know.
[...]

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:[...]

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.[...]

On Don 29.01.2004 16:38, Robert Segall wrote:[...]

Thats right.
[...]

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 ;-)