Subject: Interest in a UDP equivalent to the CONNECT method

From: Lucas Pardue <[email-masked]>
Date: Sat, 3 Feb 2018 14:27:35 +0000

Hi,

I'm wondering if there is interest from the WG in the following space before investing any more technical effort.

It recently struck me that there might be a use in iterating upon the CONNECT method, in order to support a world of UDP servers that support HTTP/QUIC. That spec neatly summarises the current state of play:

   In HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a
   tunnel to a remote host.  In HTTP/2, the CONNECT method is used to
   establish a tunnel over a single HTTP/2 stream to a remote host for
   similar purposes.

   A CONNECT request in HTTP/QUIC functions in the same manner as in
   HTTP/2.  The request MUST be formatted as described in [RFC7540],
   Section 8.3<https://tools.ietf.org/html/rfc7540#section-8.3>.  A CONNECT request that does not conform to these
   restrictions is malformed.  The request stream MUST NOT be half-
   closed at the end of the request.

   A proxy that supports CONNECT establishes a TCP connection
   ([RFC0793<https://tools.ietf.org/html/rfc0793>]) to the server identified in the ":authority" pseudo-
   header field.  Once this connection is successfully established, the
   proxy sends a HEADERS frame containing a 2xx series status code to
   the client, as defined in [RFC7231], Section 4.3.6<https://tools.ietf.org/html/rfc7231#section-4.3.6>.

The sad part here is that an HTTP/QUIC client that uses an HTTP/QUIC proxy in this mode needs to support TCP for secure connection to the remote host. This presents some resistance to moving away from TCP in the future.

I wondered if something better could exist, and Ben Schwartz and I batted some ideas around. The strongest one was the idea of a new method (e.g. UDPBIND) that would allow a client to indicate to the proxy that it wished to communicate with the remote host using UDP. Depending on the protocol being used for client-to-proxy communication some options present themselves (NB: the data exchanged is the serialization of TLS handshake and protected packet format):

  *   HTTP/QUIC
     *   DATA frames sent by client (UDP) are transmitted by the proxy to the remote host UDP port (UDP).
     *   data received by the proxy (UDP) is packaged into DATA frames, which are then transmitted to the client (UDP).
  *   HTTP/2
     *   DATA frames sent by client (TCP) are transmitted by the proxy to the remote host UDP port (UDP).
     *   data received by the proxy (UDP) is packaged into DATA frames, which are then transmitted to the client (TCP).
  *   HTTP/1.1 ?
     *   data sent by the client (TCP) is transmitted by the proxy to the remote host UDP port (UDP).
     *   data received by the proxy (UDP) is transmitted to the client (TCP).

The conversion between TCP and UDP should be treated carefully, payloads may be segmented unexpectedly.

The handling of UDP "closure" is a problem area that needs more thought.

Kind regards
Lucas

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 3 Feb 2018 17:42:50 +0200

On Sat, Feb 03, 2018 at 02:27:35PM +0000, Lucas Pardue wrote:
> 
> I wondered if something better could exist, and Ben Schwartz and I
> batted some ideas around. The strongest one was the idea of a new
> method (e.g. UDPBIND) that would allow a client to indicate to the
> proxy that it wished to communicate with the remote host using UDP.
> Depending on the protocol being used for client-to-proxy
> communication some options present themselves (NB: the data exchanged
>  is the serialization of TLS handshake and protected packet format):

Why you are assuming the data has anything to do with TLS? What would
be the other endpoint of the TLS link? If it is the proxy, that seems
overly complicated, as things can be keyed easier. If remote server,
I do not think there are any programmatically understandable ways of
using TLS in this scenario. And then there are protocols that use
DTLS or something else to secure themselves.
 
>      *   data received by the proxy (UDP) is packaged into DATA
>          frames, which are then transmitted to the client (UDP).
>   *   HTTP/2
>      *   data received by the proxy (UDP) is packaged into DATA
>          frames, which are then transmitted to the client (TCP).
>   *   HTTP/1.1 ?

There are UDP protocols that absolutely rely on segmentation, so the
segmentation needs to be preserved. I think DTLS 1.3 (as currently
drafted) is actually one of those protocols.

1:1 frame translation would be possible in HTTP/2 and QUIC (obviously
not in HTTP/1.1). However, it would change semantics of the DATA
frames from just being fragments of stream to meaningful units in
themselves.

Also, it seems to me that using any reliable streaming protocol
would run contrary to reasons applications are using UDP. TCP is so
much easier than UDP! Granted, the unpredictable delays would be much
smaller. I am not quite sure if QUIC plans to have unreliable streams
for the first version or not.
 
> The handling of UDP "closure" is a problem area that needs more

I thought UDP has no "closure". You mean client or proxy shutting down
the listener (so to free the proxy resources)?

-Ilari

---

From: Göran Eriksson AP <[email-masked]>
Date: Sat, 3 Feb 2018 15:42:11 +0000

On 2018-02-03, 15:31, "Lucas Pardue" <[email-masked]<mailto:[email-masked]>> wrote:

Just to make sure I get it right; the intent is to support the case of a  L4 proxy (L4 after connection being established) with UDP (QUIC) on the remote side, as seen from the client.

If so, +1.

Does your scenario assume only one proxy between the client and the remote host or is the case of a set of proxies in a chain included?

Best Regards
Göran

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 4 Feb 2018 14:36:47 +0000

Hi Göran,

The intent is to emulate the behavior of CONNECT as far as possible, just with UDP as the transport for the remote side.

To this end, the scenario would allow a chain. From RFC 7231 section 4.2.6:

   The recipient proxy can establish a tunnel either by directly
   connecting to the request-target or, if configured to use another
   proxy, by forwarding the CONNECT request to the next inbound proxy.

Regards
Lucas

From: Göran Eriksson AP [mailto:[email-masked]]
Sent: 03 February 2018 15:42
To: Lucas Pardue <[email-masked]>; HTTP Working Group <[email-masked]>
Cc: [email-masked]
Subject: Re: Interest in a UDP equivalent to the CONNECT method

If so, +1.

Best Regards
Göran

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 4 Feb 2018 14:54:17 +0000

Hi Ilari,

Thanks for the comments. To be clear, the intent is to emulate the use of CONNECT as far as possible. The details of how CONNECT is used across HTTP/1.1, HTTP/2 and HTTP/QUIC varies a little but the main gist is similar.

Ilari Liusvaara wrote:

> Why you are assuming the data has anything to do with TLS? What would be
> the other endpoint of the TLS link? If it is the proxy, that seems overly
> complicated, as things can be keyed easier. If remote server, I do not think
> there are any programmatically understandable ways of using TLS in this
> scenario. And then there are protocols that use DTLS or something else to
> secure themselves.

My main experience is with HTTP/QUIC so I gave that as an example. In simple terms, the client using the proxy begins a TLS 1.3 negotiation over UDP with the remote host, once keys are exchanged protected QUIC packets are used.

> drafted) is actually one of those protocols.

Noted.

> 1:1 frame translation would be possible in HTTP/2 and QUIC (obviously not in
> HTTP/1.1). However, it would change semantics of the DATA frames from
> just being fragments of stream to meaningful units in themselves.

I think this is already true of HTTP/2 and CONNECT. RFC 7540 section 8.3 states that on the stream that initiated the CONNECT request, DATA frames have a new meaning, they correspond to data sent on the (remote) TCP connection.

For HTTP/QUIC, I would imagine that a client packages QUIC packets targeting the remote host within DATA frames. The proxy unframes these and forwards them on, and vice-versa.

> Also, it seems to me that using any reliable streaming protocol would run
> contrary to reasons applications are using UDP. TCP is so much easier than
> UDP! Granted, the unpredictable delays would be much smaller. I am not
> quite sure if QUIC plans to have unreliable streams for the first version or
> not.

Ben made the same point so perhaps I'm not understanding the issue. As I understand it, if you are using a protocol on top of UDP that requires reliability, then you need to provide that. E.g in the HTTP/QUIC use case  QUIC provides the reliability assurances.

> I thought UDP has no "closure". You mean client or proxy shutting down the
> listener (so to free the proxy resources)?
>

I'm open to input here.

Kind regards
Lucas

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: Ben Schwartz <[email-masked]>
Date: Sun, 4 Feb 2018 11:19:51 -0500

In my view, a UDP counterpart to CONNECT ought to work not only for
HTTP/QUIC but also for WebRTC.  That means that it should have the ability
to receive packets from unexpected sources, as the remote party's effective
address may not be known in advance.  I don't know how to map that semantic
into HTTP/2 frames.

On Sun, Feb 4, 2018 at 9:54 AM, Lucas Pardue <[email-masked]> wrote:

> Hi Ilari,
>
> Thanks for the comments. To be clear, the intent is to emulate the use of
> CONNECT as far as possible. The details of how CONNECT is used across
> HTTP/1.1, HTTP/2 and HTTP/QUIC varies a little but the main gist is similar.
>
> Ilari Liusvaara wrote:
>
> My main experience is with HTTP/QUIC so I gave that as an example. In
> simple terms, the client using the proxy begins a TLS 1.3 negotiation over
> UDP with the remote host, once keys are exchanged protected QUIC packets
> are used.
>
> not in
> I think this is already true of HTTP/2 and CONNECT. RFC 7540 section 8.3
> states that on the stream that initiated the CONNECT request, DATA frames
> have a new meaning, they correspond to data sent on the (remote) TCP
> connection.
>
> For HTTP/QUIC, I would imagine that a client packages QUIC packets
> targeting the remote host within DATA frames. The proxy unframes these and
> forwards them on, and vice-versa.
>
> Ben made the same point so perhaps I'm not understanding the issue. As I
> understand it, if you are using a protocol on top of UDP that requires
> reliability, then you need to provide that. E.g in the HTTP/QUIC use case
> QUIC provides the reliability assurances.
>
> the

---

From: Ian Swett <[email-masked]>
Date: Sun, 4 Feb 2018 12:02:15 -0500

This seems generally useful, but are there enough motivating use cases?

---

From: Ben Schwartz <[email-masked]>
Date: Sun, 4 Feb 2018 13:10:00 -0500

I see two: HTTP/QUIC and WebRTC.  In both cases, connecting through an HTTP
proxy currently prevents UDP communication with the destination, impairing
performance and compatibility.

On Sun, Feb 4, 2018 at 12:02 PM, Ian Swett <[email-masked]> wrote:

>>> Thanks for the comments. To be clear, the intent is to emulate the use
>>> of CONNECT as far as possible. The details of how CONNECT is used across
>>> be

---

From: Albert Lunde <[email-masked]>
Date: Sun, 4 Feb 2018 12:19:24 -0600

On 2/4/2018 11:02 AM, Ian Swett wrote:
> On Sun, Feb 4, 2018 at 11:19 AM, Ben Schwartz <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     HTTP/QUIC but also for WebRTC.  That means that it should have the
>     ability to receive packets from unexpected sources, as the remote
>     party's effective address may not be known in advance.  I don't know
>     how to map that semantic into HTTP/2 frames.

CONNECT is still an HTTP method which has some notion of a stream 
transport, though it's kind of a tunnel.

SOCKS5 is a protocol for proxy transport of data which also supports 
UDP, and isn't tied to HTTP headers and framing:

https://tools.ietf.org/html/rfc1928

it might be better suited to arbitrary traffic

-- 
       Albert Lunde  [email-masked]
                     [email-masked]  (address for personal mail)

---

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Sun, 4 Feb 2018 19:23:33 +0000

On 04/02/2018, 18:13, "Ben Schwartz" <[email-masked]> wrote:
> I see two: HTTP/QUIC and WebRTC.  In both cases, connecting through an
> HTTP proxy currently prevents UDP communication with the destination,
> impairing performance and compatibility.

Not super sure, but another use case that seems to map quite naturally
is the analogue of a TCP proxy (for example, as seen in the mobile
network) with QUIC as the transport, and explicit rather than
implicit/bumped-in-the-wire.

It looks like it'd be possible for an end user to have one security
association to the QUIC transport proxy and a separate one with the
other QUIC end that gets tunnelled through the proxy.

Is my reading correct?

Cheers, thanks

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 4 Feb 2018 19:53:36 +0000

Hi Thomas,

> It looks like it'd be possible for an end user to have one security association
> to the QUIC transport proxy and a separate one with the other QUIC end
> that gets tunnelled through the proxy.
> 
> Is my reading correct?
> 

Yes that is what I had pictured. This is sometimes referred to as a "secure web proxy". Some UAs can make use of this (on TCP) by means of a Proxy auto-config (PAC) file that uses the HTTPS proxy type [1].

Regards
Lucas

[1] https://www.chromium.org/developers/design-documents/secure-web-proxy

---

From: Göran Eriksson AP <[email-masked]>
Date: Sun, 4 Feb 2018 20:42:28 +0000

On 2018-02-04, 17:24, "Ben Schwartz" <[email-masked]> wrote:

In my view, a UDP counterpart to CONNECT ought to work not only for HTTP/QUIC but also for WebRTC.  

Hi Ben,

This is interesting but it is not 100% clear to me what you mean by “also work for WebRTC” (I guess we talk about the WebRTC API as well as the RTCWEB protocol suite).

Could you describe the use case a bit more in detail? I may be a bit confused but it seems as if you propose using “QUIC CONNECT” and will then have a QUIC relay proxy in the webrtc paths. Is that correct?

If so, do you have in mind applying it to any “webrtc stream”, both media (RTP today) and data (SRTP)?

Or is it the case where HTTP tunneling is applied?

Do you assume appropriate API changes in WebRTC?

Sorry for the set of questions- may be best you describe a bit more in detail what you have in mind. I may have missed some background.

Best Regards

Göran

That means that it should have the ability to receive packets from unexpected sources, as the remote party's effective address may not be known in advance.  I don't know how to map that semantic into HTTP/2 frames.

---

From: Mike Bishop <[email-masked]>
Date: Sun, 4 Feb 2018 21:53:08 +0000

I kind of doubt any proxy would give you that.  I think the best you’re likely to get is parity with a NAT, in which the client can create a mapping (UDPBIND) and then receive incoming traffic on the resulting port.  Ideally, the client would be able to learn what client-side port has been assigned it on the proxy’s external interface, something that CONNECT doesn’t really need to expose.  Of course, since the proxy itself could be NATted, even an indication from the proxy won’t be reliable.

From: Ben Schwartz [mailto:[email-masked]]
Sent: Sunday, February 4, 2018 8:20 AM
To: Lucas Pardue <[email-masked]>
Cc: [email-masked]; HTTP Working Group <[email-masked]>
Subject: Re: Interest in a UDP equivalent to the CONNECT method

In my view, a UDP counterpart to CONNECT ought to work not only for HTTP/QUIC but also for WebRTC.  That means that it should have the ability to receive packets from unexpected sources, as the remote party's effective address may not be known in advance.  I don't know how to map that semantic into HTTP/2 frames.

On Sun, Feb 4, 2018 at 9:54 AM, Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ilari,

Noted.

I'm open to input here.

Kind regards
Lucas

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Feb 2018 10:50:47 +1100

I'm surprised that no one has mentioned TURN yet.  So let me be the first.

On Sun, Feb 4, 2018 at 1:27 AM, Lucas Pardue <[email-masked]> wrote:
> It recently struck me that there might be a use in iterating upon the
> CONNECT method, in order to support a world of UDP servers that support
> HTTP/QUIC. That spec neatly summarises the current state of play:
>
>    Section 8.3.  A CONNECT request that does not conform to these
>    ([RFC0793]) to the server identified in the ":authority" pseudo-
>    the client, as defined in [RFC7231], Section 4.3.6.
>
>
> The sad part here is that an HTTP/QUIC client that uses an HTTP/QUIC proxy
> in this mode needs to support TCP for secure connection to the remote host.
> This presents some resistance to moving away from TCP in the future.
>
> I wondered if something better could exist, and Ben Schwartz and I batted
> some ideas around. The strongest one was the idea of a new method (e.g.
> UDPBIND) that would allow a client to indicate to the proxy that it wished
> to communicate with the remote host using UDP. Depending on the protocol
> being used for client-to-proxy communication some options present themselves
> (NB: the data exchanged is the serialization of TLS handshake and protected
> packet format):
>
> HTTP/QUIC
>
> DATA frames sent by client (UDP) are transmitted by the proxy to the remote
> host UDP port (UDP).
> data received by the proxy (UDP) is packaged into DATA frames, which are
> then transmitted to the client (UDP).
>
> HTTP/2
>
> DATA frames sent by client (TCP) are transmitted by the proxy to the remote
> host UDP port (UDP).
> data received by the proxy (UDP) is packaged into DATA frames, which are
> then transmitted to the client (TCP).
>
> HTTP/1.1 ?
>
> data sent by the client (TCP) is transmitted by the proxy to the remote host
> UDP port (UDP).
> data received by the proxy (UDP) is transmitted to the client (TCP).
>
>

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 5 Feb 2018 17:50:34 +0000

> I'm surprised that no one has mentioned TURN yet.  So let me be the first.

I'm not overly familiar with TURN. Are you saying that the capabilities of this new method are already fulfilled by TURN,  that TURN could be enabled by this method, or that there are design elements to crib from TURN.

The main use case I had, HTTP/QUIC, does not suffer from peer communication issues so I find it hard to see where TURN comes in.

Regards
Lucas

---

From: Martin Thomson <[email-masked]>
Date: Tue, 6 Feb 2018 08:24:52 +1100

> I'm not overly familiar with TURN. Are you saying that the capabilities of this new method are already fulfilled by TURN,  that TURN could be enabled by this method, or that there are design elemen…

The first and last, at least in part.

---

From: Göran Eriksson AP <[email-masked]>
Date: Mon, 5 Feb 2018 21:28:18 +0000

On 2018-02-05, 18:55, "Lucas Pardue" <[email-masked]> wrote:

    

Since Ben added "WebRTC" to the discussion, Martins comment make perfect sense. Personally, I would be waiting for Ben to detail the "WebRTC" case he has in mind, which would include TURN of course, (.

+1. The HTTP/QUIC case is pretty straightforward (even though use cases are always useful of course). "WebRTC" will require an effort to clarify scope and proposed solution.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 6 Feb 2018 11:18:19 -0500

On Mon, Feb 5, 2018 at 4:28 PM, Göran Eriksson AP <
[email-masked]> wrote:

>     I'm not overly familiar with TURN. Are you saying that the
> capabilities of this new method are already fulfilled by TURN,  that TURN
> could be enabled by this method, or that there are design elements to crib
> from TURN.
>
>
> Since Ben added "WebRTC" to the discussion, Martins comment make perfect
> sense. Personally, I would be waiting for Ben to detail the "WebRTC" case
> he has in mind, which would include TURN of course, (.
>

My feeling is:
1. It would be nice for HTTP/QUIC to be self-proxying, in the same way that
HTTP/2 and its predecessors are.
2. The obvious way to do this is to add a UDP proxy method to HTTP.
3. If we're going to define a UDP proxy method, it might as well support
the other common UDP-based protocols.

As for interaction with WebRTC, I would note that right now, running WebRTC
over an HTTP proxy greatly limits the use of UDP candidates, impairing
media quality and often causing suboptimal routing (through TURN/TCP).  If
HTTP proxies could support UDP traffic (on the external interface), this
could be improved.

    The main use case I had, HTTP/QUIC, does not suffer from peer
> communication issues so I find it hard to see where TURN comes in.
>
> +1. The HTTP/QUIC case is pretty straightforward (even though use cases
> are always useful of course). "WebRTC" will require an effort to clarify
> scope and proposed solution.
>

I agree, HTTP/QUIC seems like a simpler case.  A "connection-oriented" UDP
proxy protocol (i.e. a single-destination tunnel) might suffice for
HTTP/QUIC, but it would not be convenient for WebRTC, because WebRTC (i.e.
ICE) works best when clients can receive packets from unexpected sources.
This has implications for the client<->proxy protocol.

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 6 Feb 2018 17:49:34 +0000

So to summarise the discussion on a few of the different threads that this launched:

  *   There seems to be some interest in this idea.
  *   HTTP/QUIC is one use case that does not suffer from peer-to-peer UDP issues.
  *   WebRTC is one use case that does suffer from peer-to-peer UDP issues
     *   There is overlap with TURN, which may be good or bad.
  *   Question: Are there enough compelling use cases to justify a new method?
     *   Corollary: would one high-impact use case be sufficient to justify a new method?

Apologies if I missed anything out.

Based on this feedback I’m inclined to write up a more rounded technical proposal to help frame further discussion. This might separate out the WebRTC theme to disentangle the different aspects.

Regards
Lucas

From: Lucas Pardue [mailto:[email-masked]]
Sent: 03 February 2018 14:28
To: HTTP Working Group <[email-masked]>
Cc: [email-masked]
Subject: Interest in a UDP equivalent to the CONNECT method

Hi,

   similar purposes.

   HTTP/2.  The request MUST be formatted as described in [RFC7540],<https://tools.ietf.org/html/rfc7540#section-8.3>

  *   HTTP/QUIC

  *   HTTP/2

  *   HTTP/1.1 ?

Kind regards
Lucas

----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------

---

From: Göran Eriksson AP <[email-masked]>
Date: Tue, 6 Feb 2018 18:35:09 +0000

Thanks for clarification Ben.

The WebRTC QUIC CONNECT topic is a bit clearer to me know, but writing up a draft will of course help even more. I still am pondering the question about a WebRTC API impact, but that is a discussion best suited for the WebRTC API WG I think.

Looking forward to this discussion developing further.

Best Regards

Göran

On 2018-02-06, 17:18, "Ben Schwartz" <[email-masked]> wrote:

My feeling is:

1. It would be nice for HTTP/QUIC to be self-proxying, in the same way that HTTP/2 and its predecessors are.

3. If we're going to define a UDP proxy method, it might as well support the other common UDP-based protocols.

As for interaction with WebRTC, I would note that right now, running WebRTC over an HTTP proxy greatly limits the use of UDP candidates, impairing media quality and often causing suboptimal routing (through TURN/TCP).  If HTTP proxies could support UDP traffic (on the external interface), this could be improved.

I agree, HTTP/QUIC seems like a simpler case.  A "connection-oriented" UDP proxy protocol (i.e. a single-destination tunnel) might suffice for HTTP/QUIC, but it would not be convenient for WebRTC, because WebRTC (i.e. ICE) works best when clients can receive packets from unexpected sources.  This has implications for the client<->proxy protocol.

---

From: Göran Eriksson AP <[email-masked]>
Date: Tue, 6 Feb 2018 18:44:26 +0000

When writing up the proposal, I would be hoping for a clarification about what kind of proxy we’re addressing, meaning being clear on “forward” or “reverse proxy” context.

I understand that this could potentially be left out from the draft given one limits the scope of the draft, but the example you gave in previous email- the “web proxy” configured in the browser- is a forward proxy as I see it, and the reverse proxy case, where the origin redirects the client to an end point indicating use of proxy(ies) is an interesting use case also.

So what kind of proxies did you have in mind?

Regards
Lucas

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 7 Feb 2018 08:22:49 +1300

On 07/02/18 07:44, Göran Eriksson AP wrote:
> Based on this feedback I’m inclined to write up a more rounded technical
> proposal to help frame further discussion. This might separate out the
> WebRTC theme to disentangle the different aspects.
> 
>  
> 
> When writing up the proposal, I would be hoping for a clarification
> about what kind of proxy we’re addressing, meaning being clear on
> “forward” or “reverse proxy” context.
> 
>  
> 
> I understand that this could potentially be left out from the draft
> given one limits the scope of the draft, but the example you gave in
> previous email- the “web proxy” configured in the browser- is a forward
> proxy as I see it, and the reverse proxy case, where the origin
> redirects the client to an end point indicating use of proxy(ies) is an
> interesting use case also.
> 

And then there are gateway proxies. Which are not configured in the
Browser and may not even be easily visible to it several hops down a
relay chain.

Amos

---

From: Göran Eriksson AP <[email-masked]>
Date: Tue, 6 Feb 2018 21:28:20 +0000

On 2018-02-06, 20:26, "Amos Jeffries" <[email-masked]> wrote:

+1.

Tnx for complementing.