[core] RFC 7252 - Forward Proxies

Achim Kraus <achimkraus@gmx.net> Wed, 08 January 2020 12:51 UTC

Return-Path: <achimkraus@gmx.net>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C506312011C for <core@ietfa.amsl.com>; Wed, 8 Jan 2020 04:51:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqJSelatil1h for <core@ietfa.amsl.com>; Wed, 8 Jan 2020 04:51:05 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1CC120026 for <core@ietf.org>; Wed, 8 Jan 2020 04:51:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1578487860; bh=yNBVonVyUqkbdl/WDjoj5EN0dfNjIwKZSqlu6dQhRmE=; h=X-UI-Sender-Class:To:From:Subject:Date; b=QbdCYvSDyddilKDG93L1fp7tqAWHAqXkHFZ5+Se53LmgqpHo1a4wuOFWYXRd6y/J8 1GYw8S74Z8M8OvHkP/92hfwxW0jQCFCYc7N5CJovxanN6Msqxl7iFIEklEzPub1v5U 7Rx2muRY739PW8BAL1e1BBeFFLdBAAFgx+flz7hs=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.45] ([178.2.231.191]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1McH9i-1jPLZ223lk-00clra for <core@ietf.org>; Wed, 08 Jan 2020 13:51:00 +0100
To: "core@ietf.org" <core@ietf.org>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <324677e1-06d4-a4d6-b79c-9a55c01adcbb@gmx.net>
Date: Wed, 08 Jan 2020 13:50:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:cC+bo8SCU0xJWrYc6i5cLgrRjBm+JfPnbC5kjXFNZP3KcfvwhCt Nq8ZnU86QQ01iu8pVE2uNiGrAfa/HLOQiBFSRK+Rwm10AHy4O1Y7lGSJOSksAjZ2n89vuri eGpCZW/p29piH5OcFp+zghInWI7aZUGuUYOFecpUjjT/G9VRkvke2prQjjNP3VjEFJQXEmi ZyhVeZFiDjMcG+kCwwfLw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:iWIzhQxpmD4=:hANxf3YpinJ5EEAczM5F7l AsHmV1Q+GQ8dltzMfe318iG4e+LgwUMU6SaeBlujvziaXoeLvut3Usu0nUib7DVXtFUhTrZBR cazoQrh6QhQdA5JWXYDvKvlzIujohQSupM8IfK6RJTBfyWRADQgwYK4JJ932/JIh90jJe2O2q U+pS9MwWzQVJboOKLavckEsuTR3Po6MNhSK1B8wRBttQXJHMcuHdMwrdVKGe3IMBvUG9tbpiv KQZFNHWRoxE1S2xkvzdVt8ZAFP1maqZwSU8SFhqfeIXiopeE9m/TX4+xmhRExQSgAYLYwmajY iEZ5jf0cDzLYLd43rqAiopUYk67s9hS12aaCgJY7QP+ZRDhRCuGKvd9vR56EdLr60P5m+a2IR JswHSMV5wTsDzlTvZrkgJ9lEPLNlOx0wgTuGDA+MjnFQsPLdO1TffWDVC0aaAB096941Tb7Tl 9JN+wOfzW9rI1oLsQiiOC4vz8DNCX0rH4WsVRSX1c912/sZ6+cPCT2CwVgOud0Q8QUIAp6Ab0 jqmip2MeeKqrXebqw6OioMM0BeKAgHEIODayTxNeARHpClqmS6kivQJ6HSjLeDjt6MKj/6pg5 /lkEArPNFWMvLyOHgSkwwDvbQc8mMOu1EF0jHFgIDcA8cFNxxF/O5akdHlF179iKktmfrv2Iu uKUW9D0m+mLNXSdN5JdM7T4TD46WkcvnC5CdKE/CTwrDYOMjUFkQuuFOyxZz2AJ55HRaUaIo9 nhtoNFo0rytkM//LHfdZRU2wrX8vOp8r6pR7wst6/gWDAUl03AJ52qCQrUrFbMu6BPCQggEzO RCFZiih95PSLdAwTt/XrhUbx+lAmxWkclcrRnx9LdelvIt+F9YupgAXQ8yJEkTh79zmeJyD0h mN2AAGPBePhGqPR9sO9O4TAxecFdW83v2Dl2CyyUOAPoDwvt0T8cPwcN43N2l1cEJxlXHBO+9 hfWXJpWtOkgqrIriZLr1dh/PAQTH1fQazoOIs8gjobW1ZQM5Jmyw9Ofw8Kx0i0y7EJR8wYU+r +i8ZbZxv+3Msuad3+ttl1ofN3x5lp30ZYloySJsOSut/jIqaLLY6Mz6Nh0a/UJbCQCcxCuO/0 oIh2DF2T6QaQsRJ8by5Fed1MNaJu8A6MSYBKf8NDb70nzDiNvk2l45/oVdnl2MR70uQQLKaBo m75GarB2sJ+qCqtQtoDZVVpFdYPidXzxaSTHtrQpyj4yS1vPs1R754FHcWGP2WZwQqhcSlKQA V4WJrKW6IJgFNmjy1Q4BqYhTFr4dlUsBR/3NuHreZ22I6WTGcMLzGNxnMqjk=
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/tBBHIyzuEBnos4UVb_s7cIQ_5Iw>
Subject: [core] RFC 7252 - Forward Proxies
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2020 12:51:07 -0000

Dear Core-List,

I'm currently try to spend some time in working on Californium's
"Forward Proxies" support according
https://tools.ietf.org/html/rfc7252#section-5.7.2.

Studying this section in combination with "Decomposing URIs into
Options" according https://tools.ietf.org/html/rfc7252#section-6.4 I'm
not sure, if 6.4 requires some more clarification considering 5.7.2.

Point 5 in 6.4 describes the processing for the host:

"5.  If the <host> component of |url| does not represent the request's
        destination IP address as an IP-literal or IPv4address, include a
        Uri-Host Option and let that option's value be the value of the
        <host> component of |url|, converted to ASCII lowercase, and then
        convert all percent-encodings ("%" followed by two hexadecimal
        digits) to the corresponding characters.

        NOTE: In the usual case where the request's destination IP
        address is derived from the host part, this ensures that a Uri-
        Host Option is only used for a <host> component of the form reg-
        name."

A informal description would be in my opinion, add the uri-host option,
if it's not the IP-literal of the destination (that assumes, that the
term "destination" refers to the actual proxy to send the request to).
But the text seems not to differentiate between the request's (which
maybe the proxy) and the URI destination (which will be the "final
destination", or something like that). I'm also not sure, what the "or
IPv4address" refers to.
For me it seems, that stick strict to 6.4 would cause different option
values, if a proxy is used and the "final destination" URI contains also
a (different) literal IP address. For me "strict" will then result in a
wrong request to the proxy.

Point 6 in 6.4 describes the processing for the port:

6.  If |url| has a <port> component, then let |port| be that
        component's value interpreted as a decimal integer; otherwise,
        let |port| be the default port for the scheme.

"6 ... otherwise": if a Proxy-Scheme is used, should that default port
be use? Or still the URI-Scheme's port? If the Proxy-Scheme is to be
considered, that default port maybe unclear/unknown by the client
implementation.

Best regards
Achim Kraus