Ian Bicking wrote:
The idea of requiring Page to insert a <base href> seems like it
could break existing applications, likewise getting HTTPServlet to do a
redirect seems problematic and I am not sure it is really that clean.
On Thu, 2003-01-16 at 12:21, Stuart Donaldson wrote:
One difference I found in the new algorithm vs old algorithm was when
passed a directory without a trailing '/' the old algorithm returns the
directory relying on dispatchRequest() to send a redirect. The new
algorithm treats it as a directory and finds the directory index.
The rational the old algorithm gives, is that without the trailing '/'
relative url's would be messed up.
Hmm... that is correct. I'd rather leave it up to the servlet to deal
with this, especially if we end up putting more stuff in the servlet
anyway. Specifically, HTTPServlet can send a redirect, and Page can do
like Zope, and put a <base href> in and avoid the redirect (or maybe do
the redirect anyway, since that might be more reliable).
I think that Application should be used to find the servlet. Is a
reference to a directory without a trailing '/' really a reference to
the index of that directory? What about having "foo.py" and
"foo/index.py" then you reference "/foo" I would expect "foo.py" to be
referenced. If I referenced "/foo/" then it is the directory.
Admittedly this is probably a lame analogy because you could make the
argument that it is an ambiguous result so take it with a grain of
I think if a redirect is needed, that Application should be able to do
I'm simply going from a gut feeling on this right now, and could be
swayed or overridden by those with more Webware experience.
This still raises the question of responsibility between servlet and
application. If my earlier assumption is correct, and the application
is responsible for locating the servlet, it should also be responsible
for being the primary generator of a 404 error. That means the
application would need to query the servlet to see if the servlet
supports the extraPathInfo. This could be done by adding
HTTPServlet.setExtraPathInfo() method and then that method by default
would either return a success/failure, or possibly raise a file not
found erro back to the application which would then generate the 404
error. If the servlet wanted to generate its own 404 error, it could
not raise the error, and do this.
Also, if I understand the rational for the ExtraPathInfo setting, it seems
that with ExtraPathInfo and a directory index at the root of the context, or
a directory index at the root of the default context, you generally won't
get a 404 error. We walk up the URL looking for a servlet to handle the
request, and stop there.
Yes, though that's not the current behavior (but it was the old
behavior). But I can see times when it would be useful.
I think the ExtraPathInfo setting should be a servlet by servlet basis.
The servlet can choose to handle ExtraPathInfo information. If it does not
handle it, then a 404 error would result. If it does handle it, then things
proceed as normal.
This could be implemented by simplifying the serverSideInfoForRequest*()
operation to always parse out the ExtraPathInfo. Then either
createServletInTransaction() or possible handleGoodURL() would ask the
servlet if it supported ExtraPathInfo, and if it did not, call the
Again, agreed. Catching all 404s is a fairly extreme behavior, and I'd
rather that only happen when it's specifically requested. But couldn't
HTTPServlet do the checking itself? I think we should simplify
Application, and put a bit more of the logic into HTTPServlet. I.e.,
ask forgiveness instead of permission.
Another approach, and maybe this is more what you were thinking,
HTTPServlet.awake() or maybe .respond() could call the
setExtraPathInfo() rather than the Application. But the
setExtraPathInfo() type function seems to me to be a good way for a
derived class from HTTPServlet to decide it can accept the data. The
thing I like about this, is that it does not mess with the clean
awake/respond/sleep protocol the application uses.
The default implementation of setExtraURLPath could be the place where
the decision on raising or generating a 404 error somehow is made. I
suspect from what I have seen, that the default behavior should be to
generate a 404 for compatibility with existing apps. However I would
rather solicit input on that before making a decision.