Johannes Erdfelt
johannes at erdfelt.com
Tue Oct 19 20:17:38 EDT 2004
On Tue, Oct 19, 2004, Graham Dumpleton <grahamd at dscpl.com.au> wrote: > On Oct 19 16:50, Johannes Erdfelt <johannes at erdfelt.com> wrote: > > On Tue, Oct 19, 2004, Graham Dumpleton <grahamd at dscpl.com.au> wrote: > > > I am a bit wary of directly generating an error response from this point in > > > the code. > > > > > > What may be better is to raise a Python RuntimeWarning exception with the > > > description of the problem. This will cause mod_python to still return an > > > internal server error, but one where the details would only be visible when > > > PythonDebug option is set to On. The error would also be logged into the > > > log file automatically. > > > > That's a good point. Some people may not want this level of information > > to be returned to the user. > > > > On the other hand, I hate Internal Server Error messages (and shame on > > me for returning that as the error too :). They are kind of misleading > > in this case because the error isn't internal to the server, but in the > > request from the client. > > > > To some extent, the error code that is returned is a problem since it > > causes alarms with my log analysis scripts, but I'm more concerned with > > the message that is returned. > > Well, it could still be done in Vampire as you propose, but simply have it > honour the PythonDebug setting. It may be more approriate to return a > HTTP_BAD_REQUEST if HTTP_INTERNAL_SERVER_ERROR is not appropriate > in this case. I looked at HTTP_BAD_REQUEST, but the HTTP specs seem to imply that it should only be returned when there is a parsing error during the command parsing phase. Like if the "GET" or "PUT" command is malformed. I guess it's all a matter of preference. > Unfortunately the mod_python routine for generating internal server > error responses, with details as appropriate if PyhonDebug is on isn't a > generically usable routine that could be used to do it and I don't think > it allows an alternate status anyway. Vampire could provide such a > generic routine that might even also be usable in some way from a user > content handler when they want to return errors, but with a message > when PythonDebug is set. I've actually done something similar in my old vampire-like handler. It would catch an exception and print an error message to the client. I had implemented a UserError and InternalError handler. UserError would always be sent back to the client. Generally it would be used for errors the client won't generally generate, but might be useful. I used it for the error message about query variables and in my original form processing code if a radio button variable had an invalid value or similar. InternalError would either send the error to the client if PythonDebug was enabled, or log it to the Apache error log and print a generic message to the client. This was used for internal consistency errors that are probably not useful to the client. After reading your emails, I'm sure that some administrators probably won't want errors like UserError being returned to the client. JE
|