As a **app developer**, I can **view route destination protocols** when **listing routes on the v8 CLI**

[Gerg]

Copy-pasted from: https://www.pivotaltracker.com/story/show/178978532

---

Given I am using the v8 CLI
AND I have some routes in my targeted space

When I list routes using cf routes

Then I see a new app protocol column with the appropriate destination protocols

cf routes
Getting routes for org org / space space as admin...

space   host   domain         port   path   protocol   app protocol   apps   service instance
s1      h1     example.com                  http       http1          a1
s1      h2     example.com                  http       http2          a2

---

Consider whether app protocol is the best name for this column.

---

Handle TCP and internal routes

---

Root issue: cloudfoundry/routing-release#200

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/179168197

The labels on this github issue will be updated when the story is started.

[Gerg]

There is an issue with the proposed design:

cf routes
Getting routes for org org / space space as admin...

space   host   domain         port   path   protocol   app protocol   apps   service instance
s1      h1     example.com                  http       http1          a1
s1      h2     example.com                  http       http2          a2

The app protocol column works fine if the route is mapped to a single app, however it will not work if the route is mapped to multiple apps with different app protocols.

For example, if the route h2.example.com is mapped to app a2 with protocol http1 and app a3 with protocol http2, then what do you put in the app protocol column:

cf routes
Getting routes for org org / space space as admin...

space   host   domain         port   path   protocol   app protocol   apps   service instance
s1      h1     example.com                  http       http1          a1
s1      h2     example.com                  http       ?????          a2,a3

In general, we don't display destination (route mapping) level data in the cf routes output for this reason. For example, we don't display things like destination ports, weights, or process types, even though they are all present on the destinations API.

Similarly, it doesn't look like there is an easy place to put destination protocol from the app side either:

cf app blah
Showing health and status for app blah in org org / space space as admin...

name:              blah
requested state:   started
routes:            blah.example.com, other.example.com

It doesn't seem like there is a good place to display this information without dramatically re-structuring how we present routing information on the CLI.

We could not display it on the CLI (similar to destination ports, weights, etc), but it seems odd to have a writable attribute (from #2188) that cannot be viewed. We could also not add this to the CLI for now and instead rely on application manifests as the only way to configure destination protocols.

• Greg && @ctlong

[Gerg]

Some other design options:

1. Display protocols for all destinations:

cf routes
Getting routes for org org / space space as admin...

space   host   domain         port   path   protocol   app protocol    apps   service instance
s1      h1     example.com                  http       http1           a1
s1      h2     example.com                  http       http1, http2    a2, a3

This should work well for single-destination routes, but means users can't link which protocol applies to which app.

2. Add a new cf route command to show more details about destinations:

cf route example.com --hostname h1
Showing route h1.example.com in org org / space space as admin...

domain:              example.com
host:                h1
destinations:
        app           process   weight   port   protocol
        a1            web       25       8080   http1
        a2            web       25       8181   http2
        a3            worker    25       9000   http1
        a4            web       25       9999   http1

For now, we are likely only going to implement #2188 for 8.0.0. This work could be a good candidate for 8.1.0.

cc @JenGoldstrich

[ctlong]

Finished in #2205