Subject: Fwd: WGLC: draft-ietf-appsawg-http-forwarded-02.txt

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 May 2012 09:33:53 +1000

HTTP folk,

Please have a look at this document and send along comments, especially if you're an intermediary or firewall person, or consume the existing X-Forwarded-For header.

<http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-02>

Cheers,

Begin forwarded message:

> From: Alexey Melnikov <[email-masked]>
> Subject: [apps-discuss] WGLC: draft-ietf-appsawg-http-forwarded-02.txt
> Date: 2 May 2012 4:26:50 AM AEST
> To: "[email-masked]" <[email-masked]>
> 
> Dear WG participants,
> I would like to initiate WG Last Call on draft-ietf-appsawg-http-forwarded-02.txt ("Forwarded HTTP Extension"). Please send your reviews, as well as expressions of support regarding document readiness for IESG (or not) either to the mailing list, or directly to WG chairs (Murray Kucherawy <[email-masked]> and myself). Comments like "I've read the document and it is Ok to publish" or "I've read the document and it has the following issues" are useful and would be gratefully accepted by chairs.
> 
> The WGLC will end on Friday, May 18th.
> 
> Thank you,
> Alexey as an APPSAWG co-chair.
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham
http://www.mnot.net/

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 02 May 2012 14:30:35 +1200

On 02.05.2012 11:33, Mark Nottingham wrote:
> HTTP folk,
>
> Please have a look at this document and send along comments,
> especially if you're an intermediary or firewall person, or consume
> the existing X-Forwarded-For header.
>

Okay, I've been over it with a finer toothed comb this time.

Here are the textual nits and grammer. Design issues in separate reply 
in case we end up with discussions.

** section 4 example #2 syntax error:

   Forwarded: For=192.0.2.43,"for=[2001:db8:cafe::17]:47011"
should be
   Forwarded: For=192.0.2.43,for="[2001:db8:cafe::17]:47011"

( \" moved)

* section 5.* normative MAY references are inconsistent.

5.1 ", but it can, however, be"
5.2 ", but it MAY also be"
5.3 "MAY be used for example by"
5.4 "This may be"

It looks to me like the normative MAY are not necessary since all the 
texts are informational examples of use. The 5.1, 5.2, 5.3 sentence 
structure could be aligned a bit better for more clarity as well.

** section 5.2 paragraph 1 and paragraph 3 contradict each other:

pgh 1 says "information about the user agent that initiated the 
request".
  The implication clearly being that there is only meant to be one for= 
parameter on the entire line, since there can only be one initiating 
user agent per request.

pgh 3 says "the first
    for-parameter will disclose the user agent where the request first
    was made, followed by any subsequent proxy identifiers."

.. while simultaneously explicitly describing a list of multiple.

Both of these also clash with the concept of proxy or tool originated 
requests where there is no "user agent" relevance. "client" is the term 
to use here in all paragraphs.

** section 6.1 spelling

  "note that an IPv6 adress"  =>  "address"

** section 7.1 grammer implication

Given the earlier section 4 stated the header was OPTIONAL and proxies 
MAY add or MAY delete things. The statement that "information might not 
be correctly updated" is a bit out of place.
  Dropping the word "correctly" out of that sentence brings it inline 
with the normative requirements.

AYJ

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 02 May 2012 14:32:59 +1200

> <http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-02>

** section 5.1, must it be an interface label?

what about interception ports where the TCP details are not related to 
the interface in any way and both details needed?
what about interfaces labelled with non-alphanumeric characters?

AYJ

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 02 May 2012 14:34:22 +1200

> <http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-02>

** section 5.2

Now that it is mentioning the X-Forwarded-* class of headers and 
describing security usage for Forwarded: the document needs a safe 
mapping from X-Forwarded-For to Forwarded:. I have spent quite a while 
attempting to iterate the cases and find a safe mapping method for Squid 
to use mapping the fields of XFF to records in Forwarded:, but there is 
always one case or other which fails badly.

IMO the mapping should be:
"
A recipient of X-Forwarded-For header MUST either, drop all 
X-Forwarded-For: and Forwarded: headers in the request, or drop the 
X-Forwarded-For header and place a single obfuscated identifier 
field-value in the Forwarded: header prior to any other information 
additions of its own. This must be done before interpreting either 
header.
"

For example:
  client 1.2.3.4:8765 sending
    Forwarded: for=[::1]
    X-Forwarded-For: ...

becomes:
   Forwarded: for=[::1], _abc, for="1.2.3.4:8765"

This retains the security properties of the XFF header environment 
because:
  1) Dropping is safe because both these are OPTIONAL headers.
  2) Using an obfuscated identifier and retaining the Forwarded: header 
preserves what information is likely safe but places a blocking step at 
the position of the un-trustable hop.

The other X-Forwarded-* headers need a similar security protection 
fixup in the sections they map into.

AYJ

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 02 May 2012 14:37:32 +1200

> <http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-02>

** section 6 ABNF clash between port and obfport is still a nasty 
thorn.

IMO obfport should start with a mandatory '_'. We have to special-case 
it anyway to parse the ALPHA component might as well bring it inline 
with the rules for obfuscated node and obfuscated identifier ABNF.

Alternatively why bother with obfport at all?

  As I understand/recall it the use-case was to enable for= or by= with 
a visible IP and obfscated/private port.

Would not allowing one of the listed field values be obfuscated 
identifier be better? that way the port can be omitted entirely from the 
for= and whatever detail the hop needs to obfuscate and pass on can be 
encoded inside the obfuscated identifier token.

AYJ

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 2 May 2012 07:24:14 +0200

Hi Mark,

> <http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-02>

A quick note before it escapes my mind, for 8.2. Information leak :

I would add :
   This header field must never be copied into response messages by origin
   servers or intermediaries for whatever reason as it can reveal the whole
   proxy chain to the client. As a side effect, Special care must be taken
   in hosting environments not to allow the TRACE request where the Forwarded
   field is used, as it would appear in the body of the response message.

I'll probably have other comments and agree with those raised by Amos.

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 May 2012 15:26:45 +1000

Willy - 

It's best to send comments to the apps-discuss list; I was just passing this on.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 2 May 2012 07:31:38 +0200

> It's best to send comments to the apps-discuss list; I was just passing this on.

OK will do, thanks.

Willy

---

From: Andreas Petersson <[email-masked]>
Date: Fri, 4 May 2012 11:34:03 +0200

On Wed, 02 May 2012 14:32:59 +1200
> what about interfaces labelled with non-alphanumeric characters?

Hi, 

Can you explain how you mean/give some examples?

 /andreas

---

From: Andreas Petersson <[email-masked]>
Date: Fri, 4 May 2012 13:26:20 +0200

On Wed, 02 May 2012 14:34:22 +1200
> always one case or other which fails badly.

Section 5.2 doesn't mention X-Forwarded-*.

I think it is a futile effort. In some situation it may be 
possible to find a good way. If you find a solution that works
for you, in your shop, it is of course fine to use it. 
But in general I believe it to be super hard to do it in a good
way -> "implementation specific".

> additions of its own. This must be done before interpreting either 

Dropping seems strange. I would assume it will be common to add
both headers to be backwards compatible.

>    Forwarded: for=[::1], _abc, for="1.2.3.4:8765"

That is not valid syntax.

> This retains the security properties of the XFF header environment 

I don't think you should use neither XFF nor Forwarded for security,
unless you trust the proxy that adds the header field and knows what
header field that proxy updates. That proxy should probably also drop
previous header fields, but that may also depend on how the values are
used etc.

>   1) Dropping is safe because both these are OPTIONAL headers.

Well, while it is strictly true it is probably undesired to lose that
information.

> fixup in the sections they map into.

To specify in the specification for "Forwarded" how to make a transition
from a header field that is not standardized at all seems both
irrelevant and makes the Forwarded-spec more complex than needed.

If something should be said at all it could be done in a separate
document with informal status.

Best regards,
 Andreas

---

From: Andreas Petersson <[email-masked]>
Date: Fri, 4 May 2012 13:29:46 +0200

On Wed, 02 May 2012 14:30:35 +1200
Amos Jeffries <[email-masked]> wrote:
> [...]

Agreed. :-)

 /andreas

---

From: Andreas Petersson <[email-masked]>
Date: Fri, 4 May 2012 13:49:06 +0200

On Wed, 02 May 2012 14:37:32 +1200
> with the rules for obfuscated node and obfuscated identifier ABNF.

Start it with a mandatory '_' seems fine.

 /Andreas

---

From: Peter Lepeska <[email-masked]>
Date: Fri, 4 May 2012 12:06:50 -0400

I wonder if the forwarded information should also include TCP header
options ( http://www.networksorcery.com/enp/protocol/tcp.htm#Option<http://www.networksorcery.com/enp/protocol/tcp.htm#Options>s)
based on the TCP connection carrying the original GET request.

Peter

On Tue, May 1, 2012 at 7:33 PM, Mark Nottingham <[email-masked]> wrote:

> HTTP folk,
>
> Please have a look at this document and send along comments, especially if
> you're an intermediary or firewall person, or consume the existing
> X-Forwarded-For header.
>
> > I would like to initiate WG Last Call on
> draft-ietf-appsawg-http-forwarded-02.txt ("Forwarded HTTP Extension").
> Please send your reviews, as well as expressions of support regarding
> document readiness for IESG (or not) either to the mailing list, or
> directly to WG chairs (Murray Kucherawy <[email-masked]> and myself).
> Comments like "I've read the document and it is Ok to publish" or "I've
> read the document and it has the following issues" are useful and would be
> gratefully accepted by chairs.
> >

---

From: Andreas Petersson <[email-masked]>
Date: Fri, 04 May 2012 18:36:44 +0200

On 5/4/12 6:06 PM, Peter Lepeska wrote:
> I wonder if the forwarded information should also include TCP
> header options (
> http://www.networksorcery.com/enp/protocol/tcp.htm#Option 
> <http://www.networksorcery.com/enp/protocol/tcp.htm#Options>s)

Can you provide a use case?

/andreas

---

From: Peter Lepeska <[email-masked]>
Date: Fri, 4 May 2012 16:15:52 -0400

I can think of an enterprise use case but it's pretty contrived. WAN
optimizing appliances use the TCP option field to auto-negotiate optimized
connections when appliances are present in the data path. See
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/WAASDC11.html
.

Should there be an HTTP proxy in between those optimizing appliances, the
TCP option field would be lost along with the original client source IP
address and port. However, if this information was included in the HTTP GET
Headers then the functionality could in theory be preserved.

I know it's a stretch.

Peter

On Fri, May 4, 2012 at 12:36 PM, Andreas Petersson <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJPpAWbAAoJEEaYRbQUWNlea4wP/jwcy7ZRC2caJwYv/1/9+V/u
> SkUUrAl+7H6aVrV0waOSZI2okAZQ9ezBJxJxetiDp1f6wA2h23luJXrW1SOAsANY
> VX5RTyWNwbgu51qLILDevpjHk61HvslVch4Qjh0YnOgEhWISz3eHAIzt9jocNAfo
> 5x2jf7SuzftVmy84dQlp1u5Rss4V+w8Jr9h+2I8wVxf/LDDSS5wNKXFbwBmHmEDY
> dZUnKfpf4Udu3M3JnAjBR6b2WLjSZAFWeK01bKCbZxczfCYZxgeLhMm6r641+M+t
> 9TM4YMBUQdY60L/wwKs2E+44xdyU4LtdvdI9Lbfvu/w7jBwj800lT3sUg69GqaaQ
> 5qXPKBkJ/1bZKB6u5ryPMTI2n6XMCloiII59b+MiwlCcui5+VJuowiiUZqfL3qyK
> OUvJ0S5DlnQUb9h2a87e2wKoO5tZ3udqCXf6CRaraTcvKm8H6y3kCWhXD2M3FLel
> pHEJouXpOPB6fzbcCkVO/W4ijnAtWXp0iBz6uQXLairFVRGu5kjN73RfXb53tdz/
> jqsGSjQGxMgMbElvAwk2ZpNQHgXzElvaoj7YvOAkhnikcI6+rcUhjgpTm0hWxmUu
> AUyMNOln1wAe4UMxrj2MiYXeULoWlVhZ28alGnho3tcTikyzct2cRIwxkuL+/WfH
> eY5wv8T+R/rc0fYuKC64
> =MGh5
> -----END PGP SIGNATURE-----
>
>

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 06 May 2012 13:43:38 +1200

On 4/05/2012 9:34 p.m., Andreas Petersson wrote:
> Amos Jeffries<[email-masked]>  wrote:

With the TPROXY/divert socket features in recent kernels replacing NAT 
there is a big disconnection of the TCP details and application 
listening port details.

For example an application can be listening on 192.168.1.1:3129  and 
receiving TCP packets with src 10.1.1.1:12345 dst 10.2.3.4:80. Which of 
the three IP:port values is best added to the header?

I know this only affects interception proxies which we dont *realy* want 
to cater for specifically. But it does bring up a clarity issue with the 
texts.

>> what about interfaces labelled with non-alphanumeric characters?

Using squid as an example:

   http_port 127.0.0.1:3128 name=localhost-3128
   http_port 127.0.0.1:3129 name=localhost-3129

"-" character is not matching the alpha-numeric ABNF requirements. Also 
the admin might have entered any UTF-8 characters from whatever language 
they use as the label.

AYJ

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 06 May 2012 13:51:44 +1200

On 5/05/2012 8:15 a.m., Peter Lepeska wrote:
> optimizing appliances use the TCP option field to auto-negotiate 
> optimized connections when appliances are present in the data path. 
> See 
> http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/WAASDC11.html. 
>
>
> Should there be an HTTP proxy in between those optimizing appliances, 
> the TCP option field would be lost along with the original client 
> source IP address and port. However, if this information was included 
> in the HTTP GET Headers then the functionality could in theory be 
> preserved.
>
> I know it's a stretch.
>

Not so much of a stretch. I have a client this week asking about how to 
relay TOS information from parent proxy through child proxy and use it 
on the outbound client link.

At present we have to rely on the kernel sockets API to access TOS 
values, which is lacking on a lot of systems. Long term I think that is 
the better way to go anyway but in general the principle is one to consider.

AYJ

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 6 May 2012 07:51:04 +0200

> the admin might have entered any UTF-8 characters from whatever language 

I'm used to see a similar thing at places where front SSL-offload caches
are installed. The instance name which receives the connection is named
in requests going to the backend servers, and it holds the name of the
application or of the customer, which is a 1:1 association from the
listening ip:port. I too think that we should allow a slightly larger
alphabet to permit "[:._-]" and possibly a few other characters. Some
people might also want to name the incoming interface on transparent
intercepting proxies. It's likely that the few chars above are enough
to unambiguously name network interfaces.

Given that the underscore has a special meaning when stated first, we
could have the chars above only allowed after a first ALPHANUM character.

What do others think ?

Willy

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 7 May 2012 09:34:42 -0400

Agreed.

In general, if the protocol allows all information to be forwarded across
the proxy, then there is less of a need for it to attempt to make itself
invisible to client and server, which I think creates a lot of the problems
associated with proxies.

This aligns well with the "trusted proxy" idea -- intermediary support
should be more explicit in the protocol spec to reduce the likelihood that
intermediaries will have to introduce hacks to deliver the necessary
functionality into the network.

Peter

On Sat, May 5, 2012 at 9:51 PM, Amos Jeffries <[email-masked]> wrote:

>> http://www.cisco.com/en/US/**docs/solutions/Enterprise/**
>> Data_Center/WAASDC11.html<http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/WAASDC11.html>.
>>
>>
> relay TOS information from parent proxy through child proxy and use it on
> the outbound client link.
>
> At present we have to rely on the kernel sockets API to access TOS values,
> which is lacking on a lot of systems. Long term I think that is the better
> way to go anyway but in general the principle is one to consider.
>
> AYJ
>
>

---

From: Andreas Petersson <[email-masked]>
Date: Mon, 14 May 2012 13:55:54 +0200

On Sun, 6 May 2012 07:51:04 +0200
> could have the chars above only allowed after a first ALPHANUM character.

I think it would be enough to say they are only valid in obfnode and
obfport. obfnode and obfport always starts with "_". It should also be
noted that the use of "[:]" requires the value to be quoted.

 rgds, 
   andreas

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 14 May 2012 14:37:46 +0200

> noted that the use of "[:]" requires the value to be quoted.

That's a good point. I must say I've never seen a Location or Referer
header being quoted despite their wide use of "[/:]" which are marked
as special chars. I'll raise a new issue on this subject.

Willy

---

From: John Sullivan <[email-masked]>
Date: Mon, 14 May 2012 14:20:22 +0100

> as special chars. I'll raise a new issue on this subject.

That is because those headers are defined as:

   Referer = absolute-URI / partial-URI
   Location = URI-reference
   Content-Location = absolute-URI / partial-URI

The allowed character set and escaping rules are those that apply
to those productions from RFC 3986. Those particular characters may
have special meaning within a URI, depending on their position and
URI construction, and must be % HEX HEX encoded to avoid said special
meaning, but the header values do not need to be otherwise quoted or
escaped beyond the [URI] rules.

The Forwarded header uses:

   Forwarded-v = 1#( token "=" ( token / quoted-string ) *( ";" ... ) )

Compare this with Cache-Control (which is the same but without ";"
parameters) and Content-Type/Accept (which is the same except with an
initial value that is a ( type "/" subtype ) media type, including a
literal "/" character.

So if the desired value doesn't "fit into" token, it must be a
quoted-string, where "\" is used as an escape character. Also as
httpbis puts it:

   A parameter value that matches the token production can be
   transmitted as either a token or within a quoted-string.  The quoted
   and unquoted values are equivalent.

Quite a different grammar!

Variations on that theme have sufficient use within RFC 2616/httpbis
that I think it's good to use something broadly similar. People
operating in that area ought to have the component parsers readily
available and understand their use well enough to compose them into
a total parser for the grammar defined here.

It could be argued that by limiting values to quoted-string alone any
required value can be represented and one cuts off one avenue for
confusion/incompatibility, but I think defining a new base character
set should be done only as a last resort.

John
--

---

From: Andreas Petersson <[email-masked]>
Date: Mon, 14 May 2012 17:19:29 +0200

On Tue, 01 May 2012 19:26:50 +0100
Alexey Melnikov <[email-masked]> wrote:

> read the document and it has the following issues" are useful and would 
> be gratefully accepted by chairs.
> 

We are closing in on May 18:th now. We have got plenty of good input.

To summarize, I have made a preliminary change log, covering things
that has been discussed this far. I will also mention ideas that we do
not intend to incorporate in this document.

If you have suggested something that is not in the list below I may
have missed that, please send a reminder to me in such case.

If you disagree with something in the list or have other ideas, please
let me know.

*** Intended changes ***

1.1, Section 4: Clearly mention that IPv6-addresses must be quoted.
     Also show this in examples. This also applies to IPv4 addresses
     when the port is specified.

1.2, Section 4: Have a less complex example. Also, make sure that the
     quote is placed on the right side of the "=".

1.3, Section 4: Add a note that a proxy can also add a new
     "Forwarded: .."-line, as this is equivalent. 

1.4, Section 5.*: Remove some MAY-references.

1.5, Section 5.1: Add a note that the by-parameter may be useful in a
     multi-homed environment. 

1.6, Section 5.2: Add a note that in some situations it is more relevant
     to read the address of the last proxy in the last
     Forwarded-by-field.

1.7, Section 5.2: Formulate paragraph 1 to include that the information
     is not only regarding the initiating client. Also change "user
     agent" to "client".

1.8, Section 5.5: Change the requirement to notify IANA into:
>"It is possible to register additional parameters using the IANA
>registration policy described in [RFC3864]"

1.9, Section 6: Require obfport to start with an underscore. 

1.10, Section 6 & 6.3: Include "[:._-]" as valid characters in obfnode
      and obfport. 

1.11, Section 6.1: s/zero compression/compression of zeroes/

1.12, Section 6.1: s/IPv6 adress/IPv6 address/

1.13, Section 7: Add some notes on when the header should be preserved
      or not. Duscussed under #7:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05535.html

1.14, Section 7: Note that this header field is not possible to combine
      with the information from the via-header field with certainty.

1.15, Section 7.1: Remove the word "correctly" from: 
      "[...] information might not be correctly updated [...]"

1.16, Section 7.x: Encourage proxies to convert X-Forwarded-*
    when possible. 

1.17, Section 8.2: Add the text W. Tarreau mentions:
      (with the change of must -> should in the first sentence)
> This header field should never be copied into response messages by
> origin servers or intermediaries for whatever reason as it can reveal
> the whole proxy chain to the client. As a side effect, special care
> must be taken in hosting environments not to allow the TRACE request
> where the Forwarded field is used, as it would appear in the body of
> the response message.

1.18, Section 8: Add a section or a note about privacy considerations.

*** Suggestions we intend NOT to incorporate ***
(somewhat incomplete)

2.1, TCP-options. This can be standardized in a separate document.

2.2, Complex transition schemes. 

Best regards,
 Andreas Petersson

---

From: Andreas Petersson <[email-masked]>
Date: Mon, 14 May 2012 17:50:31 +0200

On Mon, 14 May 2012 17:19:29 +0200
> 1.10, Section 6 & 6.3: Include "[:._-]" as valid characters in obfnode

":" is obviously not suited in obfnode/obfport.
I suggest:
obfnode = "_" 1*( ALPHA / DIGIT / "." / "_" / "-" )
obfport = "_" 1*( ALPHA / DIGIT / "." / "_" / "-" )

 /andreas

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 14 May 2012 23:48:40 +0200

> a total parser for the grammar defined here.

OK but I mean, I've been used to send IPv6 X-Forwarded-For headers
without quotes and have seen some of these headers sent with a port
number without quotes either. So maybe we're causing quotes to become
necessary only because we just allow token / quoted string in the
value then ? Maybe it would make sense to enlarge the allowed character
set for values in order to avoid making quoted-strings necessary for
most usages ?

> set should be done only as a last resort.

OK in theory but in practice I'm fairly sure we'll see IPv6 addresses
sent unquoted because a number of implementations will not have noticed
they became mandatory. That's why sometimes widening a character set to
better fit what it is supposed to represent makes a lot of sense. This
can even be done by slightly extending the grammar :

   Forwarded-v = 1#( token "=" ( ipv4 / ipv6 / token / quoted-string ) *( ";" ... ) )

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 May 2012 23:55:34 +0200

On 2012-05-14 23:48, Willy Tarreau wrote:
> ...
> ...

The downside is that you can't use an off-the-shelf parser component, 
which I believe is a pretty big downside.

The HTTP community has been inventing new microsyntaxes for many years, 
and as far as I can tell, most header field parsers out there are broken 
beyond belief. We need less of them, even if this means that a few edge 
cases will be more verbose than necessary.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 15 May 2012 07:23:35 +0200

Hi Julian,

> cases will be more verbose than necessary.

I see, and indeed this is a good point. Considering the number of times
I've heard "hey, your product sends me commas in IP addresses", it is
certain that people don't understand what they retrieve there.

Cheers,
Willy

---

From: John Sullivan <[email-masked]>
Date: Tue, 15 May 2012 12:15:02 +0100

> cases will be more verbose than necessary.

This. Each new syntax risks getting it wrong (even if in this case
it ought to be fairly safe) - just look at the horrible horrible
mess that is the history of Set-Cookie.

In addition to the headers I pointed out yesterday that use
close variations on the theme, the definition of Expect appears
to be almost *exactly* this syntax - except that it makes the
value part ( "=" ( token / quoted-string ) ) optional. This allows
for the sending of value-less flags without having to use the
somewhat grotty flag="" construct. Perhaps adopting that syntax
verbatim would be a good idea?

Note also httpbis-p2 S3.1, "Considerations for Creating Header Fields",
particularly:

   Many header fields use a format including (case-insensitively) named
   parameters (for instance, Content-Type, defined in Section 6.8 of
   [Part3]).  Allowing both unquoted (token) and quoted (quoted-string)
   syntax for the parameter value enables recipients to use existing
   parser components.

John
--

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 15 May 2012 14:30:13 +0200

> verbatim would be a good idea?

I too think so, it can be useful for boolean attributes (eg: 'secure'
instead of 'secure="yes"' or things like this).
 
Regards,
Willy