| Willy Tarreau | d1142aa | 2007-01-07 13:03:59 +0100 | [diff] [blame] | 1 | 1 type générique "entité", avec les attributs suivants : |
| 2 | |
| 3 | - frontend *f |
| 4 | - l7switch *s |
| 5 | - backend *b |
| 6 | |
| 7 | des types spécifiques sont simplement des entités avec certains |
| 8 | de ces champs remplis et pas forcément tous : |
| 9 | |
| 10 | listen = f [s] b |
| 11 | frontend = f [s] |
| 12 | l7switch = s |
| 13 | backend = [s] b |
| 14 | |
| 15 | Ensuite, les traitements sont évalués dans l'ordre : |
| 16 | - listen -> s'il a des règles de l7, on les évalue, et potentiellement on branche vers d'autres listen, l7 ou back, ou on travaille avec le back local. |
| 17 | - frontend -> s'il a des règles de l7, on les évalue, et potentiellement on branche vers d'autres listen, l7 ou back |
| 18 | - l7switch -> on évalue ses règles, potentiellement on branche vers d'autres listen, l7 ou backends |
| 19 | - backend -> s'il a des règles l7, on les évalue (quitte à changer encore de backend) puis on traite. |
| 20 | |
| 21 | Les requêtes sont traitées dans l'ordre des chaînages f->s*->b, et les réponses doivent être |
| 22 | traitées dans l'ordre inverse b->s*->f. Penser aux réécritures de champs Host à l'aller et |
| 23 | Location en retour. |
| 24 | |
| 25 | D'autre part, prévoir des "profils" plutôt que des blocs de nouveaux paramètres par défaut. |
| 26 | Ca permettra d'avoir plein de jeux de paramètres par défaut à utiliser dans chacun de ces |
| 27 | types. |