| setuid | thumbs, I've been doing this a very long time, I'm well aware of how to hunt down errors in the error log |
| megaspaz | setuid: no you aren't |
| yango | i said that you said that he said that you said that i read when you said i read what you read when i said you read i said that! |
| setuid | yango++ :) |
| thumbs | yango: you confuse me |
| Covener | <setuid> Just some flub about rewriteloglevel not to be snarky, but best not to fight too hard on this one |
| thumbs | it's not irrelevant 'flub' EVERY error is relevant. |
| setuid | Covener, Not sure what you're referring to, but the 'flub' was AGAIN, not relevant to mod_rewrite not working The point is, that error in the log DID NOT EXIST, until I caused it to happen, by putting AllowOverride All in the <Directory> clause for that vhost. So looking at the error log showed nothing, as I stated originally. |
| Covener | setuid: I'm reading in context in the buffer, are you? <setuid> Ok, now when I have AllowOverride set to All, I get "Internal Server Error" <setuid> thumbs, Absolutely nothing of interest shows up in the error log |
| thumbs | setuid: at this point, best to admit you're wrong and move on. |
| setuid | Covener, Correct. |
| thumbs | an 'Internal Server Error' will ALWAYS generate a relevant error entry in the error_log. ALWAYS. |
| setuid | thumbs, Nope, because I'm not "wrong". You suggested I look in the error log _before_ I caused the error to show up. I replied that nothing was in the error log, _because_ there were no errors, since AllowOverride None was doing its job... the job of ignoring .htaccess where the RewriteLogLevel line was. |
| Covener | thumbs: (barring a third-party module or a content generator like proxy/cgi) |
| thumbs | setuid: again, drop it. Covener: in some cases, yes. |
| yango | but even then "premature end of headers" is an indicator that the problem lies in the script |
| megaspaz | indeed white screen of death |
| fajita | white screen of death is php's way of telling you the script didn't run. |
| Covener | yango: I'm referring to when the CGI generates an expclicit 500 response |
| thumbs | Covener: that is evil. |
| Covener | yango: which is similiar to a proxy-like module forwarding a 500 generated oat the origin server |
| yango | well, yeah. but that sucks anyway |
| Covener | thumbs: legitimate though I guess, but definitely rare compared to just a busted cgi issuing bad / no headers |
| thumbs | Covener: I seriously doubt he would have implemented that directive. Covener: a good observation, nonetheless |
| yango | i wonder if there's a way to throw a 500 from the cgi and let apache log something at the same time |
| thumbs | I'd have to try it. |
| yango | yes... I'm too sleepy to try right now :) |
| riczho | yango: In Perl, die does that. |
| megaspaz | you could just raise an unhandled exception as well python will log it's stack trace to the error log hard to read, but better than nothing iirc, perl should also just log its errors to the error log as well |