Just a thought. It would be nice to have the same output contol of the 404 Not Found error extended to the 500 ISE, 403 Forbidden, 503 Service Unavailable and other commonly used http status responses.
Wishlist - Custom Error Template Handling
Started by Ben, Apr 06 2012 09:16 AM
4 replies to this topic
#2
Posted 09 April 2012 - 11:29 AM
404, 500 and 301 are the only http error status headers PW sends. But of those, the only one you don't really have output control over in the 500. The reason for that is that it indicates a fatal error has occurred, and we need to stop execution asap rather than rendering any other pages and getting into a possible infinite loop.
If you wanted to send another header, you could create a page containing the content you want to display and do it like this:
If there's demand for something like that to be included like it is with a 404 in PW, then we could add it down the road.
If you wanted to send another header, you could create a page containing the content you want to display and do it like this:
if($error) {
header('HTTP/1.1 503 Service Unavailable');
echo $pages->get('/tools/http-status/service-unavailable/')->render();
}
If there's demand for something like that to be included like it is with a 404 in PW, then we could add it down the road.
#3
Posted 09 April 2012 - 11:39 AM
Hmm, it seems possible to get a 403 out of a PW install too but I think that's from the .htaccess rules, not from the PW code itself.
Ryan, maybe it would be better to have .htaccess issue a 404 instead of a 403 in order not to leak any information about directory structure on the server? For example, installing from git adds a /.git subfolder. Direct access attempts to this are correctly prevented but a 403 confirms its existence where a 404 would be ambiguous.
Ryan, maybe it would be better to have .htaccess issue a 404 instead of a 403 in order not to leak any information about directory structure on the server? For example, installing from git adds a /.git subfolder. Direct access attempts to this are correctly prevented but a 403 confirms its existence where a 404 would be ambiguous.
Steve ☧
#5
Posted 10 April 2012 - 11:35 AM
Netcarver I think that makes sense, though the 403 strikes me as more semantic (if that's the right word?) here. Since these are from Apache, not PW, I'm not sure they necessarily hide it any better since Apache's 404 is unlikely to be the same as PW's. PW is subtle and quiet (unlike WordPress or Drupal) but completely hiding PW's existence is not something we are necessarily trying achieve. If we were, we'd have to go a lot farther than disguising blocked directories. Even then, no matter how well a software disguises itself, if you've got access to the code, there are nearly always ways to figure it out. Though maybe more transparency is something we should aim for down the road, as PW is already very quiet about itself and it's not a stretch to take it further. I'm just afraid of getting too far into this as I'm not sure 100% disguise/transparency is possible with any reasonably complex software.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users













