Wt

It seems that in case of progressive bootstrap I can only use setInternalPathValid in the application constructor.

Is it possible to set 404 dynamically? When a user navigates to some internal path which is not 'supported' within an active Wt session, I would like to send 404 code:

MyApp::MyApp(const Wt::WEnvironment &env) :
    Wt::WApplication(env)
{
    internalPathChanged().connect(this, &MyApp::onInternalPathChanged);
}

void MyApp::onInternalPathChanged(std::string path)
{
    root()->clear();

    if (path == "/one")
    {
        root()->addWidget(new WText("page 1"));
    }
    else if (path == "/two")
    {
        root()->addWidget(new WText("page 2"));
    }
    else if (path == "/three")
    {
        root()->addWidget(new WText("page 3"));
    }
    else
    {
        root()->addWidget(new WText("ERROR: Page not found"));
        // here I would like to send code 404
    }
}

Hey Alan,

True. The system we use to change paths is to not actually load a new HTML page, but we handle this as an event within the page, not so different from a mouse event. We do have communication with the server, but in the form of an Ajax request (or WebSocket message). Ignoring websockets here, returning a 404 on this request would not be visible to the user, nor would it be correct since it's not a request for the missing page, it's a request for information from the server on how to update the current page.

Now what you could do (which would be correct) if you really want the 404 HTML page, is to redirect the user (WApplication::redirect()) in case the internal path is invalid, which would spawn a new session an generate the 404 server-side. That's even something Wt could do, as a configuration option. This also has as main draw-back that the user loses his session (going back would be a new session).

Koen Deforche wrote:

Now what you could do (which would be correct) if you really want the 404 HTML page, is to redirect the user (WApplication::redirect()) in case the internal path is invalid, which would spawn a new session an generate the 404 server-side. That's even something Wt could do, as a configuration option. This also has as main draw-back that the user loses his session (going back would be a new session).

It does not really matter for me if a user loses his session on redirect. All I want is to keep the initial url in browser. If a user types http://myapp/some-bad-url, his input should remain the same, but he should get the 404.

Is it possible to generate the 404 server-side using Wt after a redirect?

Yes, that falls under the conditions listed above.