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:Ian, 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 salt.
I think if a redirect is needed, that Application should be able to do it.
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 handleBadURL.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.
-Stuart-
