Chuck Esterbrook wrote:
> At 04:24 PM 1/10/2001 -0800, Terrel Shumway wrote:
> >*UNLESS* there is no slash, in which case, it bails and returns the bare
> >directory, leaving dispatchRequest to discover the anomaly and do the
> >redirect. Very clever indeed.
> Well, clever or ugly. I think you can take your pick in this case.
> >So all URLDecoder has to do is return a bare directory name.
> I guess that is nice...
> >404s are easy too: just return the path of an arbitrary, non-existent file.
> >(None will not work, since that is a signal to the MultiplexURLDecoder to
> >check the next decoder.)
> Good point. Although returning some arbitrary path that you hope doesn't
> exist feels shaky. Perhaps we should raise an exception?
I agree. I was thinking of using tempfile.mktemp, but that is still shaky. On
Windows, you could use an illegal character, like ":" or "|", but unix allows
about everything to occur in a filename.
> >ExceptionPath is not needed. (It was inspired by Zope's raise HTTPRedirect(
> >location ).)
> Is that related to the previous paragraph? You lost me on that one...
Yes, it is. Zope defines a set of exceptions specificially for redirects and
failure status codes. I thought that was a good use of exceptions, so my
first design was based on the assumption that a URLDecoding could, for
raise HTTPRedirect( path_info + "/" )
and Application would catch the exception and send the redirect.
When I discovered that there were no such exceptions in webware,
I was disappointed, but not daunted. I wanted to make it work without
mucking around with too much of Applications's internals.
However, since you seem to favor the idea, I would very strongly
recommend such a set of exceptions.
In the current situation, the same condition is tested twice -- once in
serverSidePathForRequest, and once in Application.dispatchRequest.
Using an exception allows the inner routine to communicate exactly
what the problem is, and do so immediately.
With your approval, I will go ahead and setup an exception class
hierarchy, and make the necessary changes to Application.dispatchRequest()
to handle the exceptions appropriately.