Re: draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list

On Jul 3, 2012, at 12:05 PM, Barry Leiba wrote:

> In case anyone here is interested and not already following
> apps-discuss, I started a discussion thread with this same subject
> line on apps-discuss@ietf.org.  Go there to comment.  Here's an
> archive pointer to the beginning of the thread:
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06521.html

Hi Barry,

I don't believe that discussion and draft belongs on apps-discuss.
HTTP belongs here.  [In fact, I'd have to say that apps-discuss is
turning into an oligarchy with arbitrary specification scope, instead
of its original intention as a coordination forum amongst the
individual ADs+WGs that did the real work, but that's another story.]

Regarding your comments on Forwarded:

> Last paragraph of Section 4:
>>   Given that a proxy wishes to add a Forwarded header field to the
>>   outgoing request, if the incoming request has no such header field,
>>   the proxy simply adds the header field with the list of parameters
>>   desired.  If, on the other hand, the incoming request has such a
>>   header field, the proxy can either add a comma and the list of
>>   parameters, or add a new instance of the header field.  A proxy MAY
>>   remove all Forwarded header fields from a request.  It MUST, however,
>>   ensure that the correct header field is updated in case of multiple
>>   Forwarded header fields.
> 
> I find this confusing,

I find that confusing too.  It should just say that the new value
MUST either be appended to the existing field-value or appended
as a new field at the end of the header block.

> and I question the value of having more than
> one way of representing things.  Why would a proxy want to add a comma
> and a list, rather than adding a new instance?

For performance and implementation reasons.  Some proxies will store
the field-value as a compounded hash of ordered list values until some
generic routine writes the value as a single field; some will have already
sent the received header fields downstream and thus have no other
choice but to append as a new fieled; others will choose to append
a separate Forwarded at the end in order to avoid buffer copies
or for easier debugging.

I don't think an HTTP header field needs to define one way to do it.
We have left it unspecific in order to maximize flexibility in
implementation.

> If a proxy later wants
> to selectively remove earlier information, how would it safely do it when
> some had been added as list items into another header field?

I assume by looking at the information it wants to selectively remove.
It would be more common to simply delete the existing field and create
a new one on the way downstream.

>  Doesn't it
> complicate things to have to support various combinations?

Yes, but that is governed by HTTP/1.1 parsing rules.

> How would I
> choose between these?:
> 
>     Forwarded: for=192.0.2.43,for=198.51.100.17
> 
>     Forwarded: for=192.0.2.43
>     Forwarded: for=198.51.100.17

They mean the same thing in HTTP (as in RFC822, MIME, etc.).

> You either need to explain the pros and cons, or just provide one way
> to do it.  I guess I'd want to see a good reason for not just having one
> header field per proxy.  I realize that existing fields use this
> mechanism, but we have a chance to be specific in a new specification.

No, we don't.  HTTP header fields cannot redefine HTTP parsing.
All this field is doing is restating (unnecessarily) the facts
implied by the list rule in HTTP field parsing.

> It's also very awkward to have punctuation precedence that's backward
> from how it works in English (and again, I know this is used elsewhere).
> Here, commas are more powerful than semicolons, so you might have
> something like this:
> 
>   Forwarded: for=192.0.2.43;proto=http,for=198.51.100.17;proto=https
> 
> As someone who reads English, I find the way that gets grouped to be
> surprising and unsettling, because I expect the break between "43" and
> "proto=http" to be *stronger* than the break after "proto=http", and
> it's not.

People don't read HTTP header fields.  This precedence is a leftover
from MIME field parsing and it makes far less sense to create
specialized parsers for each new field defined.  The only header fields
that got it wrong are Cookie and Set-Cookie, which resulted in more
interoperability problems than all of the rest of HTTP combined.

....Roy

Received on Thursday, 5 July 2012 20:50:15 UTC