Hello Guillaume,

Thank you for your input. It seems I had not subscribed to all
notifications in the doc; my mistake.

The route service url must be https; this is enforced by the routing API
and CC API. As the url is always https, Gorouter doesn't use Upgrade to
establish the TLS connection.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Mon, Nov 30, 2015 at 11:40 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi Shannon,

I'm wondering whether my comment last thursday on the design doc went
unnoticed. In case the google doc notification settings need a fix, here is
a copy:







*Can the route service url still be using HTTPS protocol instead of plain
HTTP, as to preserve confidentiality of routed exchanges, in particular
when the route service is accessed through the internet ?Would the gorouter
then use the usual HTTP Upgrade to TLS as per
https://www.ietf.org/rfc/rfc2817.txt
<https://www.google.com/url?q=https://www.ietf.org/rfc/rfc2817.txt&sa=D&ust=1448920443296000&usg=AFQjCNG7Ma5Bgjn97bZkKaPVo6aCqaYzkg>
section 5.2 ?If this is the case, then I would expect off-the-shelf proxies
not the add the Via header to the request (i.e honor the RFC2817 specs).If
this is not the case (i.e. CONNECT tls upgrade is not requested), then the
expected behavior is closer to a reverse proxy than a forward proxy.
Wouldn't this defeat the purpose of using off-the shelf forward proxy
software/equipments ?*

Thanks,

Guillaume.

On Thu, Nov 26, 2015 at 12:02 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

As an F5 and CF user we wouldn't have an issue changing this setting. I
wonder if F5 had a good reason to set this to "Remove" by default?

Mike

On Wed, Nov 25, 2015 at 12:39 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

The CF Routing team has nearly reached MVP for a feature called Route
Services. This feature extends the possibilities for how Marketplace
Services (and user-provided service instances) can extend the functionality
of the Cloud Foundry platform. By fulfilling integrations with the HTTP
routing tier in CF (Gorouters) and/or with the service broker API,
developers will be able to inject a marketplace service into their
application request path or dynamically configure a network component
already in the request path. This enables Marketplace Services to provide
API gateway features like rate limiting, authentication, request
transformation, logging, anaylytics, etc.

In support of the use case whereby a developer inserts a component into
the request path, the integration with the CF router requires service
authors to honor a few custom headers:

X-Cf-Forwarded-Url - The url to which the Route Service should forward
the request after processing.
X-Cf-Signature - An encrypted header used by the router to validate
requests and prevent loops. Route Services should not strip this header.
X-Cf-Metadata - Used by the router, in addition to a private key, to
decrypt the Signature header. Route Services should not strip this header.

Rather than use the custom X-Cf-Forwarded-Url header, we've been
exploring how we could support Route Services implemented as standardized
forwarding proxies per the HTTP RFC spec. Our proposal would require Route
Services to append their hostname to the *Via* header when forwarding
the request back to CF.

*Our primary concern is that the F5 load balancer will strip the Via
header by default [1]. Is it reasonable to require operators to switch this
setting from "Remove" to "Preserve", in order to support Route Services in
a CF deployment?*

We welcome your feedback; our proposal for this change is open for
public comment:
https://docs.google.com/document/d/1YYusMwGlAz91Mcd6gjZYiV_igkeAHRL-XedJPr10BZ8/edit#

[1]
https://support.f5.com/kb/en-us/products/wa/manuals/product/wa-concepts-11-2-0/18.html

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.