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.
On Sun, Apr 17, 2016 at 11:43 AM, Stefan Mayr <stefan(a)mayr-stefan.de
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.