On Thu, 2003-01-16 at 16:35, Stuart Donaldson wrote: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).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.It could break things... but it *is* faster, and in many cases is a better way to do it. Anyway, leaving it up to the servlet at least makes this an option -- if Application is in charge of the redirect then there's no option.
Ok, I can go along with that...
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.Having foo/ and foo.py is ambiguous -- I don't think it will work even now. That's just too weird to support anyway.
Ok ok ok .. I said something about a lame example... ;-)
Agreed that this is too much for 0.8. But what would you propose we do? Current behavior with ExtraPathInfo turned on and using the NewAlgorithm code does not pass all of WebKit/Testing. Test # 8 for example according to the test should redirect from /WK to /WK/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.I think Application is way too heavy, which is why I think this should be moved elsewhere -- the servlet should be completely able to handle this, and in turn give the application developer more power (since changing servlet behavior is easy through subclassing, but changing Application is hard). I'm not sure this should happen for 0.8 -- 0.8 is almost completely ready, and this could introduce new bugs, or make subtle changes to the semantics of URL parsing. Actually, I now feel sure this shouldn't happen for 0.8.
This either isn't causing a big problem right now, or people have found ways around it. I might just opt for discussing it in the release notes as an issue when ExtraPathInfo is set, and also point out the intended change in how we handle that for a post 0.8 release.
Exceptions would be a cleaner way to pass some things back. I have a patch which handles closing down when flush() encounters an error which raises an exception which is subclassed from EndResponse that seems to work well. I plan on waiting until after 0.8 before introducing it. And if you are also thinking of using Exceptions more, perhaps we should discuss the class design for exceptions. ... But that's another thread...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.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.Application *has* to find the servlet, because only once the servlet is found do you know what factory to use, and how that factory is supposed to work. But as soon as that happens, Application doesn't have to be responsible.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.Well, we can change default behavior by changing HTTPServlet -- that gives us the backward compatibility we'd want. So long as all this happens during HTTPServlet.awake(), then servlets won't have to be changed (unless they want to take advantage of the new options). I think this should be done as an exception. I've already been planning to use exceptions more, though I was planning to keep the exceptions inside the servlet itself (i.e., HTTPServlet.respond() would catch and handle all the exceptions). But since a 404 can happen without any servlet being called, we should do it a bit more globally. The one thing I hadn't figured out was the best way to generate the HTTP response -- the code is easy enough, but the text should be customizable. The text could be created by forwarding to exception-specific servlets for each error. That's my current thought on the matter. Anyway, it might work like, somewhere in Application: try: self.awake(transaction) self.respond(transaction) self.sleep(transaction) except(EndResponse, HTTPException), e: if isinstance(e, HTTPException): # some how delegate to e to figure out how to continue the # response.
-Stuart-
