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.
> 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.
> 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.
> > 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.
--
Ian Bicking Colorstudy Web Development
[EMAIL PROTECTED] http://www.colorstudy.com
PGP: gpg --keyserver pgp.mit.edu --recv-keys 0x9B9E28B7
4869 N Talman Ave, Chicago, IL 60625 / (773) 275-7241
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
