- From: Andreas Petersson <andreas@sbin.se>
- Date: Fri, 8 Apr 2011 15:36:03 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "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 Fri, 8 Apr 2011 18:49:32 +1000 Mark Nottingham <mnot@mnot.net> wrote: > > On 08/04/2011, at 8:31 AM, Thomson, Martin wrote: > > > On 2011-04-07 at 22:08:49, Karl Dubost wrote: > >> Do we have a survey of who does what? > >> X-Forwarded-For is used by Opera Mini servers. What about others? > > > > Some form of standardization of this would be useful for us. We plan to use this for more than just logging. Of course, we'll cope without a formal definition. > > > > I'll note that adding a new header is nice, but it actually means more work - we still have to process X-Forwarded-For to support all the existing stuff. Is the "X-" so offensive? Is there a reason not to simply specify what everyone does. > > > It's not so much that; it's that there's no interop on the contents of X-Forwarded-For for IPv6 headers (AFAIK), so we should take the opportunity to define a new header that specifies it well. > > While we're at it, I'd like to see extensibility points added; there are a bunch of bits of per-hop metadata that would be nice to allow in here, instead of defining separate headers. For example, in some use cases it'd be good to identify the receiving address, as well as the sending one. > > E.g., > > Forwarded-For: 1.2.3.4:5678; by=4.3.2.1:3128, 5.6.7.8:9012; by=3.2.1.0:80 > > -- > Mark Nottingham http://www.mnot.net/ > > > > It's probably better to get a real specification than trying to specify something that's been used in the wild for a long time without being specified. Especially it is important to clarify how to handle IPv6. Mark, I'm a bit skeptic about a parameter list. Doing this header field more complicated makes the threshold for implementing support for it higher. There is also more likely that people will handle it in wrong and obscure ways. What do the list think? What parameters would be relevant? ("by"? "port"? "proto"? "host"? other..?) Also, I'd like to know if the list have opinions on whether this should be published as an informational rfc or if we should try making it a standard tracks rfc. rgds, Andreas Petersson
Received on Friday, 8 April 2011 13:36:42 UTC