Re: [core] RFC 7252 - Forward Proxies

Klaus Hartke <hartke@projectcool.de> Sat, 11 January 2020 13:04 UTC

Return-Path: <hartke@projectcool.de>
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 CCEE3120046 for <core@ietfa.amsl.com>; Sat, 11 Jan 2020 05:04:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 OB3EG1RAR0o8 for <core@ietfa.amsl.com>; Sat, 11 Jan 2020 05:04:03 -0800 (PST)
Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 36824120013 for <core@ietf.org>; Sat, 11 Jan 2020 05:04:02 -0800 (PST)
Received: from mail-qk1-f170.google.com ([209.85.222.170]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1iqGQp-0003qi-00; Sat, 11 Jan 2020 14:03:59 +0100
Received: by mail-qk1-f170.google.com with SMTP id x1so4493818qkl.12 for <core@ietf.org>; Sat, 11 Jan 2020 05:03:58 -0800 (PST)
X-Gm-Message-State: APjAAAVTD063WDJsXDnqaGaYKUEBBMQjIGJ4p3imgepVDymjWw7dY/Bh mtLsRJGfXS9eMyKJiva5wW8ytATWNba7XQI3xZU=
X-Google-Smtp-Source: APXvYqw4cIOBGX7KR/r/j7DgAk8vbyYlkXKA6vYj8YwBG+f8moYps+ZlbC2mplNTjN0OVMRL9Yyx2s8NEGenTdJG7ek=
X-Received: by 2002:a05:620a:6db:: with SMTP id 27mr7746604qky.453.1578747837850; Sat, 11 Jan 2020 05:03:57 -0800 (PST)
MIME-Version: 1.0
References: <324677e1-06d4-a4d6-b79c-9a55c01adcbb@gmx.net> <CAAzbHvYA4nX2ZaL__+yuk8W1e0JXZTx5D4fTgW0F3nJTat0spA@mail.gmail.com> <d192fb34-31eb-e9b6-d446-782d8145ca16@gmx.net>
In-Reply-To: <d192fb34-31eb-e9b6-d446-782d8145ca16@gmx.net>
From: Klaus Hartke <hartke@projectcool.de>
Date: Sat, 11 Jan 2020 14:03:21 +0100
X-Gmail-Original-Message-ID: <CAAzbHvZymn-3mUqATAW_NC4KNK3w6oFLJKrCVdQFnE3MVtWWgQ@mail.gmail.com>
Message-ID: <CAAzbHvZymn-3mUqATAW_NC4KNK3w6oFLJKrCVdQFnE3MVtWWgQ@mail.gmail.com>
To: Achim Kraus <achimkraus@gmx.net>
Cc: "core@ietf.org" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1578747843; 61040539;
X-HE-SMSGID: 1iqGQp-0003qi-00
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/T4kDbNIfAMtn2gmhVvBj_L43Mq0>
Subject: Re: [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: Sat, 11 Jan 2020 13:04:08 -0000

Achim Kraus wrote:
> In my understanding the, CoAP URI-Host option will be "example.com" and
> not "198.51.100.1", otherwise hosts with multiple virtual server will
> not be able to differentiate the logical request destination.

Oh, sorry. I changed the example at some point from "example.com" to
"198.51.100.1" and apparently didn't change all instances. Here's the
corrected example:

   If a client wants to GET a representation of
   <coap://198.51.100.1:12345/.well-known/core>,
   then the CoAP options always encode
   <coap://198.51.100.1:12345/.well-known/core>,
   regardless of the destination of the UDP datagram.

Of course, the same is true for "example.com":

   If a client wants to GET a representation of
   <coap://example.com:12345/.well-known/core>,
   then the CoAP options always encode
   <coap://example:12345/.well-known/core>,
   regardless of the destination of the UDP datagram.

> Also in my understanding, the port, IP-literal and IPv4address (the none
> regname variants), are only included, if they differ from the
> destination (which will be the porxy's address in case of a proxy).

Yes, exactly. In pseudo-code:

  |url| = the request URI
  |scheme| = the <scheme> component of |url|
  |host| = the <host> component of |url|
  if the <port> component of |url| is present then
    |port| = the <port> component of |url|
  else
    |port| = the default port number for |scheme|
  endif

  if a forward-proxy is configured then
    include a Proxy-Scheme option with value |scheme|
    |transfer-protocol| = the protocol of the forward proxy
    |destination-host| = the IP address of the forward proxy
    |destination-port| = the port number of the forward proxy
  else
    do not include a Proxy-Scheme option
    |transfer-protocol| = the protocol indicated by |scheme|
    |destination-host| = |host| resolved to an IP address
    |destination-port| = |port|
  endif

  if |host| equals |destination-host| then
    do not include a Uri-Host option
  else
    include a Uri-Host option with value |host|
  endif

  if |port| equals |destination-port| then
    do not include a Uri-Port option
  else
    include a Uri-Port option with value |port|
  endif

(Necessary data conversions omitted for brevity.)

>  > It's the port number of the request URI (or, if the port number in
> the request URI is omitted, the default port number for the scheme of
> the request URI). It's not the port number of the forward proxy.
>
> My question was rather, if it's the default port of the proxy scheme
> (maybe http), or the requests coap-uri-scheme.

It's the default port number for the scheme of the request URI.


Klaus