Today the CF Routing team added the ability for an Envoy proxy deployed as the edge router for CF (using istio-release) to return a 503 instead of a 404 for a requested route when the mapped app is stopped or crashing. 

We are thrilled as this represents the first new routing feature in Cloud Foundry enabled by our next-gen routing subsystem based on Istio and Envoy. See the attached GIF for a micro-demo. 

While this is test-driven and CI'd functionality, I want to clarify that istio-release is considered experimental/alpha. 

For more on our initiative to leverage Istio and Envoy, see https://docs.google.com/document/d/1LgLY0g39fzpg1_4zTckbH1mOuuSKGvYwp2tkakoe9ys/edit

How to reconcile these use cases:

Given one shared domain mycorp.com
And a wildcard route from that domain, *.mycorp.com
And an app mapped to the wildcard route that returns a 503
I expect that a request to any subdomain of mycorp.com, at any path, to
receive a 503.

Given smoke test that maps a route to an app
Then deletes the app or unmaps the route
Then make a request to the route
and expects a 404 in response
I expect smoke tests to pass.

Smoke tests need a domain that does not have a wildcard route mapped to this
503 app.
- The smoke tests could create a shared domain and delete it. The drawback
is users may see a domain come and go while tests are run.
- In addition to shared domains you may have wildcard routes for, keep a
spare shared domain that does not have this wildcard route. Call it a
sandbox. Use it for smoke tests.




--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-How-can-we-customized-404-Not-Found-tp4501p4913.html
Sent from the CF Dev mailing list archive at Nabble.com.

Hi Amit,

Am 17.04.2016 um 21:10 schrieb Amit Gupta:

Hi Stefan, Mike,

For real applications, would you want a common 503 page for all
applications on the platform, or would your different applications have
different custom domains, with custom 503 pages for each domain.

For my current use case we need the 503 page as a catch-all for stopped
applications in all application domains. It displays a "nice" generic
message and tries not to break marketings seo efforts :-)
For more specific customer information (down till monday hh:mm) we can
deploy another staticfile application and map the application domain to it.

If the latter, then you probably wouldn't have the wildcard route on the
same domain as the default app domain used in the smoke tests.

If the former, then what sort of assertion do you think the smoke tests
should make to assert that the app has been cleaned up and is no longer
routable (without introducing false positives where the app is still
routable but returning a bad response code for some other reason)?
Thinking about the smoke tests in isolation, you might think to make the
response-code-check injectible as configuration to the smoke tests. But
from the perspective of the operator setting up the whole system and
maybe deciding whether or not to run smoke tests, they might not even
have deployed CF yet, let alone set up a 503 page, so it would be
awkward to have the operator decide and configure up front what
output/response code the smoke tests look for.

Not sure what the optimal answer is here, any thoughts?

I'm thinking about a correct answer since I've read the source code last
friday. Regardless of my preference of a 503 service unavailable to a
404 file not found - having a feature (wildcard for default application
domain) breaking a general smoke tests feels wrong.

At the moment I like the idea how some applications do domain
validation: they require you to put a file with some kind of key or uuid
onto your webserver or into a dns txt record. For cloud foundry we could
use something similar: deploy a file containing a specific id. If we try
to fetch the content of this url and it doesn't contain this id the
application is gone. It is basically like a negated version of the
current test. Instead of expecting a specific string when the
application is deleted (404) we expect a specific string (0xdeadbeef?)
not to be in the response string.

Amit

On Sun, Apr 17, 2016 at 11:43 AM, Stefan Mayr <stefan(a)mayr-stefan.de
<mailto:stefan(a)mayr-stefan.de>> wrote:

Hi,

Am 14.04.2016 um 18:14 schrieb Mike Youngstrom:

We passed the smoke tests by:

* Only returning a 503 if the requested route exists.
* Embed the old 404 page text in a comment of the returned html.

Mike


I verified this today: only the the text "404" is required to pass
the smoke tests. So I created a 503 service unavailable page
containing an html comment: <!-- CF: 404 -->

Good enough as a temporary workaround. I'd still consider this as a
bug in the smoke tests. When you use wildcard routes for real
applications this won't work.

Regards,

Stefan Mayr

Hi Stefan, Mike,

For real applications, would you want a common 503 page for all
applications on the platform, or would your different applications have
different custom domains, with custom 503 pages for each domain.

If the latter, then you probably wouldn't have the wildcard route on the
same domain as the default app domain used in the smoke tests.

If the former, then what sort of assertion do you think the smoke tests
should make to assert that the app has been cleaned up and is no longer
routable (without introducing false positives where the app is still
routable but returning a bad response code for some other reason)?
Thinking about the smoke tests in isolation, you might think to make the
response-code-check injectible as configuration to the smoke tests. But
from the perspective of the operator setting up the whole system and maybe
deciding whether or not to run smoke tests, they might not even have
deployed CF yet, let alone set up a 503 page, so it would be awkward to
have the operator decide and configure up front what output/response code
the smoke tests look for.

Not sure what the optimal answer is here, any thoughts?

Amit

Hi,

Am 14.04.2016 um 18:14 schrieb Mike Youngstrom:

We passed the smoke tests by:

* Only returning a 503 if the requested route exists.
* Embed the old 404 page text in a comment of the returned html.

Mike

I verified this today: only the the text "404" is required to pass the
smoke tests. So I created a 503 service unavailable page containing an
html comment: <!-- CF: 404 -->

Good enough as a temporary workaround. I'd still consider this as a bug
in the smoke tests. When you use wildcard routes for real applications
this won't work.

Regards,

Stefan

We passed the smoke tests by:

* Only returning a 503 if the requested route exists.
* Embed the old 404 page text in a comment of the returned html.

Mike

Hi,

Am 14.04.2016 um 13:23 schrieb James Leavers:

The end of this presentation [1] from the CF Summit has an example of
creating a wildcard route to route 404s to an app, using cf map-route.

[1]
http://berlin2015.cfsummit.com/sites/berlin2015.cfsummit.com/files//pages/files/summit-berlin.pdf

On 14 April 2016 at 11:20:17, Stanley Shen (meteorping(a)gmail.com
<mailto:meteorping(a)gmail.com>) wrote:

Thanks Mike.
Could you show me how can I do things like that, of if there are some
document about it?

If there are other ways to do that?

Thanks,
Stanley

This week we did basically the same
- map application with a wildcard domain
- change the errorpage
- change the statuscode to 503 service unavailable (search engines
should not remove us from their index because of a 404)

We used a staticfile application with a modified nginx.conf to achive
this. Michal Kuratczyk put a simplified prototype into his github repo
(https://github.com/mkuratczyk/maintenance)

Warning: this broke the smoke tests for Pivotal Cloud Foundry 1.6

Regards,

Stefan Mayr

The end of this presentation [1] from the CF Summit has an example of creating a wildcard route to route 404s to an app, using cf map-route.

[1] http://berlin2015.cfsummit.com/sites/berlin2015.cfsummit.com/files//pages/files/summit-berlin.pdf

Thanks Mike.
Could you show me how can I do things like that, of if there are some document about it?

If there are other ways to do that?

Thanks,
Stanley

We customized our 404 mapping wildcard routes to an app. We also display a
503 if the route exists.

Mike

When we accessing an APP which is not up or not existed, the CF will display error message like:

404 Not Found: Requested route ('test.domain.name') does not exist.

Can we customize it, and how can we do that?


Thanks in advance.