WtReply's 404 issue
Added by con abs almost 13 years ago
Hello wt developers!
It seems that wt responds 404 status only on serving static file or WResource that does not exist.
In other world, all path handled by the path change handler, e.g. void handPathChange( const string& path ) always get 200 ok, even if the path is invalid( suppose I have methods to determine ).
This behaviour is NOT search engine friendly, according to google's guide: http://www.google.com/support/webmasters/bin/answer.py?answer=181708
So, I want to know, what should I do if I decide to set the WtReply's status to be 404 in my handlePathChange?
Replies (5)
RE: WtReply's 404 issue - Added by Koen Deforche almost 13 years ago
Hey,
You point at an actual deficiency in Wt's internal path handling API. Currently there is indeed no way to generate a 404. I believe that we should aim at adding this to the API so that a 404 page is a plain result of the handlePathChange().
How about adding a method void WApplication::setInternalPathValid(bool valid) which, when set invalid generates a 404 response in case of a plain HTML session, but has no effect for an Ajax session. The contents of the '404' page would be unchanged from now: this allows you to have a customized 404 that is entirely in the same style as valid pages.
This method would continue to generate 404 pages until reset to setInternalPathInvalid(false). So you would need to make sure you call this for every 'valid' path as well.
Regards,
koen
RE: WtReply's 404 issue - Added by con abs almost 13 years ago
Hi koen,
Thanks for your reply. It would be nice if the next release includes setInternalPathValid.
How about adding a method void WApplication::setInternalPathValid(bool valid) which, when set invalid generates a 404 response in case of a plain HTML session, but has no effect for an Ajax session.
A clever solution. I hope search engines will never be able to deal with ajax in the future :-)
some effort for 404 - Added by con abs over 11 years ago
I have tried to modify the wt source code to enable this feature. According to the log:
- [modify] The old behaviour was to assume 200 ok by default. But now I am setStatus-ing (200) in WtReply::send.
- "GET /path/not/existed/ HTTP/1.0" 200 ...
- ...
- My application starts.
- ...
- [modify] The old behaviour was to assume 200 ok by default. But now I am setStatus-ing (404) in WtReply::send.
- "GET /?wtd=...&request=style HTTP/1.0" 404 ...
My conclusion: since the http status code of /path/not/existed/ is determined before the WApplication start, the feature of generating http code other than 200 cannot be done by the wt library user currently. At least not possible with only few lines modification in the library source.
RE: WtReply's 404 issue - Added by Koen Deforche over 11 years ago
Hey,
There is indeed no way to do this without changing the library.
We really should have a feature that can be enabled which assumes that some internal path is invalid until in code you assert that you can handle it.
WApplication::setInternalPathDefaultValid(false); // is true by default, you will usually change at startup of the application
WApplication::setInternalPathValid(true); // is default-valid by default, you will usually set this for every path change
Regards,
koen
even more - Added by con abs over 11 years ago
It's nice if wt can return specific server status: 404 (Not Found), 301 (Moved Permanently)
see http://redmine.webtoolkit.eu/issues/1407