[cf-dev] How can we customized "404 Not Found"

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[cf-dev] How can we customized "404 Not Found"

Stanley Shen
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.
Reply | Threaded
Open this post in threaded view
|

[cf-dev] Re: How can we customized "404 Not Found"

Mike Youngstrom

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

Mike

On Apr 7, 2016 9:18 AM, "Stanley Shen" <[hidden email]> wrote:
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.
Reply | Threaded
Open this post in threaded view
|

[cf-dev] Re: Re: How can we customized "404 Not Found"

Stanley Shen
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
Reply | Threaded
Open this post in threaded view
|

[cf-dev] Re: Re: Re: How can we customized "404 Not Found"

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.


On 14 April 2016 at 11:20:17, Stanley Shen ([hidden email]) 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
Reply | Threaded
Open this post in threaded view
|

[cf-dev] Re: Re: Re: Re: How can we customized "404 Not Found"

Stefan Mayr
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 ([hidden email]
> <mailto:[hidden email]>) 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
Reply | Threaded
Open this post in threaded view
|

[cf-dev] Re: Re: Re: Re: Re: How can we customized "404 Not Found"

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

On Thu, Apr 14, 2016 at 9:56 AM, Stefan Mayr <[hidden email]> wrote:
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 ([hidden email]
<mailto:[hidden email]>) 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

Reply | Threaded
Open this post in threaded view
|

[cf-dev] Re: Re: Re: Re: Re: Re: How can we customized "404 Not Found"

Stefan Mayr
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
Reply | Threaded
Open this post in threaded view
|

[cf-dev] Re: Re: Re: Re: Re: Re: Re: How can we customized "404 Not Found"

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.

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

On Sun, Apr 17, 2016 at 11:43 AM, Stefan Mayr <[hidden email]> 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

Amit, CF OSS Release Integration PM
Pivotal Software, Inc.
Reply | Threaded
Open this post in threaded view
|

[cf-dev] Re: Re: Re: Re: Re: Re: Re: Re: How can we customized "404 Not Found"

Stefan Mayr
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 <[hidden email]
> <mailto:[hidden email]>> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] Re: Re: Re: Re: Re: Re: Re: Re: How can we customized "404 Not Found"

Shannon Coen
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.
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] How can we customized "404 Not Found"

Shannon Coen
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
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7979) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_

stopped app 503 Envoy.gif (17M) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] How can we customized "404 Not Found"

Shannon Coen
In reply to this post by Shannon Coen

[Edited Message Follows]

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
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7979) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_

stopped app 503 Envoy.gif (17M) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] How can we customized "404 Not Found"

David McClure
Nice! Love the gif demo :)

On Wed, May 2, 2018 at 6:32 PM, Shannon Coen <[hidden email]> wrote:

[Edited Message Follows]

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


_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7984) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_