Bug #7393


setInternalPathValid( false ) in Wt::Application::initialize() generates 200 instead of 404

Added by Ray . over 4 years ago. Updated about 4 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


I tried setInternalPathValid( false ) in my override of Wt::Application::initialize(), and performed a wget on a url. The code returned is '200 OK'.

I think I should be getting 404.

I even went so far as issuing three statements in a row:

setInternalPathValid( false );

setInternalPathDefaultValid( false );

quit( "quit" );

But I still obtain a return code of 200.

Is there something else required?

This is Wt from git on August 4, 2019.

Actions #1

Updated by Roel Standaert over 4 years ago

If you're not using "progressive bootstrap mode", and your user agent is not recognized as being a bot or is on the Ajax blacklist, then you will always first get a special bootstrapping page.

This page will determine some information about your browser, and if JavaScript is supported in your browser it will request some JavaScript that loads your WApplication (it will redirect to a plain HTML version otherwise). Only then initialize will be called. At this point it is already too late to send a different response code.

In progressive bootstrap mode, the browser will always get a plain HTML version first (calling initialize), and will then upgrade the page to be JavaScript-based (calling enableAjax). In this case the server can actually send a different response code.

If the browser is recognized as being a bot or is on the Ajax blacklist, then it will always get a plain HTML version, and it is possible for the application to send a 404 response code.

You can configure these things with the following tags in wt_config.xml:

  • <progressive-bootstrap>
  • <user-agents type="bot">
  • <user-agents type="ajax" mode="black-list">
Actions #2

Updated by Ray . over 4 years ago

My progressive-bootstrap mode is indeed already set to true.

I can run tcpdump against a non-ssl port, and I see that there is only one page interaction with my server. When running with 'tcpdump -n -s0 -x -X port 80', I see in the tcpdump packet decode, that my message text is present, indicating that intialize() has been properly processed.

Therefore, if I understand your remarks properly, since I do have progressive-boottrap mode enabled, and the response I see is from initialize(), and I have my agent as a bot and black-list, it is at that point when the response code should be 404.

Since I am using Wget as my bot simulator, I have put that in both the black-list and bot sections. I still receive a 200 response.

<!-- .Crappy browser. -->
<!-- .Wget. -->













.Sogou web spider.



Log file:

Jan 7 14:50:47 nuc8i7hvk01 App: ydBwzpJaOtZ3AhFY,environment userAgent: Wget/1.20.3 (linux-gnu)

The code in initialize():

if ( 4 <= m_environment.internalPath().size() ) {

if ( std::string::npos != m_environment.internalPath().find( ".php", m_environment.internalPath().size() - 4 ) ) {

BOOST_LOG_TRIVIAL(info) << sessionId() << ",initialize() - no php - " << m_environment.clientAddress();

std::string sMessage( "no php here" );

root()->addWidget( std::make_uniqueWt::WText( sMessage ) );

setInternalPathValid( false );

quit( sMessage );


The wget command:

$ wget

---2020-01-07 14:57:42---

Connecting to connected.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [text/html]

Saving to: 'me.php.17'

me.php.17 [ ] 2.00K ---.-KB/s in 0s

2020-01-07 14:57:42 (86.5 MB/s) - 'me.php.17' saved [2045]

The applicable content of the response showing the 'no php here' from the statement:

$ grep php me.php.17

no php here

Actions #3

Updated by Roel Standaert over 4 years ago

Right, I didn't check with initialize(), just in the constructor of WApplication. It looks like it doesn't work when you do it in initialize(), indeed. This might not be an easy fix. It should work if you do it in your application creator callback or in the constructor of your WApplication.

However, for what I think you're trying to accomplish you may want to look into using a static WResource. You can add one with WServer::addResource.

Actions #4

Updated by Roel Standaert over 4 years ago

On second thought, it looks like you're trying to catch all paths that end in .php, I guess that's something that'll be hard to accomplish with a static resource at the moment.

Actions #5

Updated by Ray . over 4 years ago

I did look at WServer::addResource to catch all the paths, but seemed to be more work that what it was worth.

I did move the code into the constructor. That did provide the 404 response code.

Perhaps a note in the documentation to indicate where setInternalPathValid() is effective might be helpful?

Thank you.

Actions #6

Updated by Roel Standaert over 4 years ago

I have in the meantime pushed a commit that should make this work in initialize too.

Actions #7

Updated by Roel Standaert over 4 years ago

  • Status changed from New to Resolved

Now that it works in initialize, this description should normally be accurate:

You can use this function in response to an internal path change event (or at application startup) to indicate whether the new (or initial) internal path is valid. This has only an effect on plain HTML sessions, or on the first response in an application deployed with progressive bootstrap settings, as this generates then a 404 Not-Found response.

So I'll set this to resolved.

Actions #8

Updated by Roel Standaert about 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF