- From: Andreas Petersson <andreas@sbin.se>
- Date: Thu, 28 Apr 2011 11:48:36 +0200
- To: Willy Tarreau <w@1wt.eu>
- Cc: Mark Nottingham <mnot@mnot.net>, "Thomson, Martin" <Martin.Thomson@commscope.com>, Karl Dubost <karld@opera.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Tue, 19 Apr 2011 07:51:27 +0200 Willy Tarreau <w@1wt.eu> wrote: > On Tue, Apr 19, 2011 at 09:01:35AM +1000, Mark Nottingham wrote: > > I like it. Producing it is easy, and there are less special cases for parsing than the format I suggested. > > Then let's specify all the possible fields. Quite a number of people > like to also specify the original destination, and some like to set > the original Host header when their reverse-proxies rewrite it before > passing on the request. > > So we could have something like (non exhaustive) : > - from > - to > - proto > - host > > Or maybe even better, let's have all the information available in > separate fields for easier parsing : > > - family (v4/v6) > - src4 > - src6 > - sport > - dst4 > - dst6 > - dport > - host > - proto > > Cheers, > Willy > I don't think it would be that much harder to parse out the address family. By specifying family at one place seems strange if you have incoming on IPv4 and outgoing on IPv6. src/from and dst/to should be unique within one proxy step. I also think it is not so much gain by having separate port-parameters. By specifying only "from" and maybe "to" as a token that should look like an IP-address you can also fairly clear say in the standard that this only have a meaning at the proxy that appended the value (Hi PHK!). /Andreas Petersson
Received on Thursday, 28 April 2011 09:49:48 UTC