IETF Logo Mail Archive

[apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list

Barry Leiba <barryleiba@computer.org> Tue, 03 July 2012 18:33 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F289021F8700 for <apps-discuss@ietfa.amsl.com>; Tue, 3 Jul 2012 11:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.788
X-Spam-Level:
X-Spam-Status: No, score=-102.788 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8M+4AvEof1EA for <apps-discuss@ietfa.amsl.com>; Tue, 3 Jul 2012 11:33:03 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E64A321F8703 for <apps-discuss@ietf.org>; Tue, 3 Jul 2012 11:33:02 -0700 (PDT)
Received: by qcac10 with SMTP id c10so3192382qca.31 for <apps-discuss@ietf.org>; Tue, 03 Jul 2012 11:33:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=v4Jof8rZBkSYYcVSqZzB21V9MgtpV0wogaGvJsogvVo=; b=M8o85RbLRivekfz/2g8lQVNDSaSBRj9A14ls+AbKiOEZDpPRtUMsMGO67ufL0OfazU fKLHmCg9Wnq49iPxAFitd40l/GSmTh1uc9SiHIPcYUBB/m92INZtPF1pzwj4/rWL4Oy6 cCKdUjFBjhCZYjg2OCIy+xJRO++UEID3O7dVTtcHkMNkwIIR1QMtV5aUA7RxiquWG5wp Pi86w2lle55kfy+4M2gkdFGDQnYK/OhdppfTxTXR7qIPo7RdfsQdtbRwyZKxCMHbXpB5 vyH6B209AXlGNMTeUfo11hQ4cnxNBuOkbNFRZKRN+AoAIJfbktK/zYhs4S11Ru6qrLVa LZWQ==
MIME-Version: 1.0
Received: by 10.229.137.72 with SMTP id v8mr9230679qct.79.1341340391034; Tue, 03 Jul 2012 11:33:11 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.229.245.85 with HTTP; Tue, 3 Jul 2012 11:33:11 -0700 (PDT)
Date: Tue, 03 Jul 2012 14:33:11 -0400
X-Google-Sender-Auth: TaW4xa1L8PE-MKU4gs-0Oga9nqo
Message-ID: <CALaySJJkoHJnNYbVhc4gQGhz_HdG1iF1baFtK4pGwve-smsZ-g@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Apps Discuss <apps-discuss@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jul 2012 18:33:28 -0000

In my AD review of draft-ietf-appsawg-http-forwarded-05 I found myself
significantly bothered by the fact that there are multiple ways to
represent the same thing, that proxies are giving the choice of how to
add their information (and delete older, inappropriate information),
and, therefore, that consumers of the information have to cope with it
in multiple ways.

Here's a re-edit of my comment to the document editors:

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, 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?  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?  Doesn't it
complicate things to have to support various combinations?  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

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.
Is there a good reason not to be?

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.

I think this point is significant enough that I really need to bring it up on
the mailing list and get the working group's opinion.

Barry

v2.23.0 | Report a Bug | By Email