Re: How can we customized "404 Not Found"

Amit Kumar 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.

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?


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


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.

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.



Join to automatically receive all group messages.