David Mossakowski wrote:
>
> Anders,
>
> I apologize if I totally missed the mark or the wall it was on but I'm capable
> of infinite stupidity. Anyways, I only try to help.
Talk about self deprecation ;-)
>
> Anders Kristensen wrote:
>
> > Hi,
> >
> > I'm trying to implement the 2.1 version of the servlet API and I have a
> > question about how the RequestDispatcher mechanism is supposed to work
> > plus a report of a couple of bugs in JSDK 2.1.
> >
> > RequestDispatcher.include makes it possible to include the output of
> > another servlet into the output of the invoked servlet and the included
> > servlet sees the same info in response to getServletPath, getPathInfo,
> > getRequestURI as does the original servlet.
> >
> > This appears to me to be a problem when the included resource is a
> > static file being served by a (system) FileServlet. In this case the
> > FileServlet would use the getPathTranslated (or something similar) to
> > figure out which file it should ship back. However, if it was invoked
> > from some other servlet using, say,
> >
> > RequestDispatcher disp = ctxt.getRequestDispatcher ("/somepath.txt");
> > disp.include(request, response);
> >
>
> I don't understand what's happening here. Use getResource to include a static
> file. You just said at the beginning that include is to include the output of
> another servlet. Why do you then talk about including a static file by the
> same means?
Well, I won't try to explain why I think this facility is in the servlet
API but it is. My question is how the writers of the spec imagine this
to work with servlets that use getPathInfo() to do their work. Are they
supposed to test whether there's <long attribute> defined in teh request
object first or what?
>
> >
> > it wouldn't see "/somepath.txt" in response to getPathTranslated. It is
> > possible to achieve the desired behaviour by having FileServlet first
> > check the request attribute javax.servlet.include.path_info and only if
> > this returns null use getPathInfo. Is this how the JSDK/JWS works?
> > This basically means that *all* servlets using the extra path info needs
> > to perform this extra step, as they won't otherwise work with the
> > inclusion mechanism, and that seems a bit clunky to me. Maybe it would
> > be better for included servlets to see altered request info (as does
> > servlets forward()'ed to)?
> >
>
> I don't understand. How can you see /somepath.txt in any part of request?
Well that's what a FileServlet would usually see as the result of
getPathInfo (give or take the leading '/'). This isn't the case when teh
FileServlet was invoked indirectly via RequestDispatcher.include,
though.
> You
> are not processing the request in the static file (somepath.txt) but you are
> processing request in servlet to which you want to include a file. You would
> see what you are talking about from within the included servlet.
Nope.
>
> >
> > Anther question: Is it OK for a path argument to getRequestDispatcher
> > to include a query string? I guess so since include() arranges for it to
> > appear in the javax.servlet.include.query_string request attribute. But
> > on the other side a forwarded request doesn't report those params. What
> > gives?
> >
>
> You mean like this:?
> getServletContext().getRequestDispatcher("/servlet/SomeServlet?param=two")
> .include(request,response);
Yes.
>
> I don't see why not if that's what you mean.
>
Well, neither do I but if you try it out you'll see that in teh
forwarded request the arguments are not available through
getParameter().
> >
> > Also, I believe the following are bugs in JSDK 2.1:
> >
> > o RequestDispatcher.include throws an exception if the
> > ServletOutputStream has already been obtained. This is the
> > correct behaviour for forward but not for include.
>
> It seems to work fine for me.
It doesn't for me.
>
> >
> > o When a request URI has no extra path, getPathInfo() returns the
> > empty string rather than null.
>
> Seems to work fine too.
What do you mean it works fine? This is contrary to what teh spec says.
>
> >
> > o Parameters in an HTTP URL are URL decoded but the servlet path
> > isn't (try for example "%2Fsnoop").
> >
>
> [host]/servlet%2FSnoopServlet
>
> Works fine too
Not for me. (BTW I use JSDK 2.1 with JDK 1.2.1 on WinNT 4.)
--
Anders Kristensen <[EMAIL PROTECTED]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
