summaryrefslogtreecommitdiffstats
path: root/doc/design-thoughts/backends-v0.txt
blob: d350e229e9a21980b38d8fb83a52c5825270cb64 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
1 type g�n�rique "entit�", avec les attributs suivants :

  - frontend *f
  - l7switch *s
  - backend  *b

des types sp�cifiques sont simplement des entit�s avec certains
de ces champs remplis et pas forc�ment tous :

  listen   = f [s] b
  frontend = f [s]
  l7switch = s
  backend  = [s] b

Ensuite, les traitements sont �valu�s dans l'ordre :
  - 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.
  - frontend -> s'il a des r�gles de l7, on les �value, et potentiellement on branche vers d'autres listen, l7 ou back
  - l7switch -> on �value ses r�gles, potentiellement on branche vers d'autres listen, l7 ou backends
  - backend  -> s'il a des r�gles l7, on les �value (quitte � changer encore de backend) puis on traite.

Les requ�tes sont trait�es dans l'ordre des cha�nages f->s*->b, et les r�ponses doivent �tre
trait�es dans l'ordre inverse b->s*->f. Penser aux r��critures de champs Host � l'aller et
Location en retour.

D'autre part, pr�voir des "profils" plut�t que des blocs de nouveaux param�tres par d�faut.
Ca permettra d'avoir plein de jeux de param�tres par d�faut � utiliser dans chacun de ces
types.