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);
>
> 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)?
>
One way to deal with this is make your file-serving servlet work when it is
executed directly, or as an included servlet, like this:
String pathInfo =
request.getAttribute("javax.servlet.include.path_info");
if (pathInfo == null)
pathInfo = request.getPathInfo();
String pathname =
getServletContext().getRealPath(pathInfo);
Now, "pathname" contains the absolute pathname of the file to be returned, no
matter how this servlet is called.
>
> 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?
>
The ability to include a query string on an include() call was a recent
change. I expect that the "forward" case will be clarified in the 2.2
servlet API spec -- probably by becoming the request parameters that the
forwarded-to servlet sees.
You might try this under the recently released JSWDK servlet engine, which
will track the recent changes and clarifications much more closely than the
original JSDK 2.1 release.
>
> 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.
This is correct behavior on include as well, in some circumstances. If the
original servlet has done a getWriter(), the included servlet will throw an
exception if it calls getOutputStream(). LIkewise, if the original servlet
has done a getOutputStream(), the included servlet cannot call getWriter().
It only works if both the original servlet and the included servlet use the
same technique (either output stream or writer).
>
> o When a request URI has no extra path, getPathInfo() returns the
> empty string rather than null.
> o Parameters in an HTTP URL are URL decoded but the servlet path
> isn't (try for example "%2Fsnoop").
>
These do sound like bugs.
>
> Regards,
> Anders
>
Criag McClanahan
___________________________________________________________________________
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