I agree completely with this approach. In real world applications filtering is
often necessary, especially for authentication and authorization. One current
client has spent weeks developing a filter in C that basically just duplicates
part of the Java code already present in servlet form. We'd *much* rather just
use the Java code, but we need access checking for everything running on the web
server (servlets, HTML, and JSP) and there's currently no reasonable way of
doing this with Java in the client's environment (NES on HPUX).
I look forward to seeing the spec and implementation, Vince!
- Dennis
Vince Bonfanti wrote:
>
> On 4/12/99 5:24 PM, Jason Puyleart wrote:
> >
> >I have read dozens of emails similar to the message below and find this
> >response to be excellent. I have similarly run into the same problem and am
> >wondering if ServletExec has any plans to implement a FileServlet - or
> >other solutions for this issue.
> >
>
> We think that rather than implementing a FileServlet, a better solution
> to this problem (and similar problems) is to introduce the concept of
> HTTP Request Filters to the Servlet API, similar to the concepts
> supported by NSAPI and ISAPI.
>
> In brief, a Request Filter will be able to examine *every* incoming
> request to the web server (not just servlet requests), and take a number
> of actions:
>
> 1. It could return a response to the client. This could be any valid HTTP
> response, including 401 Not Authorized, 302 Moved Temporarily (redirect),
> or 200 OK (a normal HTML page).
>
> 2. It could instruct the web server to perform an "internal redirect,"
> which would cause the web server to process the request with an alternate
> URI specified by the Request Filter.
>
> 3. It could add, remove, or modify the HTTP request headers (which be
> "seen" by subsequent filters, and the servlet that processes the request,
> if any).
>
> 4. It could add headers to the HTTP response, even if the Request Filter
> itself doesn't send the reponse.
>
> 5. It could retrieve the HttpSession object associated by the request; it
> could add, remove, or modify the objects contained within the HttpSession.
>
> 6. It could implement a custom logging function.
>
> 7. It could do nothing, and let processing of the request continue
> normally.
>
> We're working on a detailed proposal and an experimental implementation,
> both of which will be made public some time after the release of
> ServletExec 2.1 (planned for early June). We hope the proposal will be
> considered by the "expert group" for inclusion in a future version of the
> Servlet API.
>
> Vince Bonfanti
> New Atlanta Communications, LLC
> http://www.newatlanta.com/
>
> P.S. While the Servlet API in its current form beats CGI hands-down, we
> think the lack of Request Filter functionality still leaves servlets at a
> disadvantage versus NSAPI/ISAPI extensions for some applications (such as
> implementing login checking). Our proposal is an attempt to address this
> weakness.
>
> >>Christopher Cobb wrote:
> >>>I am hitting a wall trying to implement my desired login architecture.
> >>What I want is this. A user wants to get to ProtectedPage.html, but I want
> >>to interpose a login-checking servlet, >which forces the user to login if
> >>necessary, then sends them to the desired page after successfully login in.
> >>>
> >>> [...]
> >>> Now the problem. If I try to use forward() to get to
> >>> /path/to/ProtectedPage.html,
> >>> it fails because static .html pages are not supported by forward.
> >>
> >>I'm afraid this may depend on how the servlet engine developer has
> interpreted
> >>the specification and whether the engine is an integrated part of the web
> >>server
> >>or an add-on engine.
> >>
> >>Web servers with a built-in servlet engine (e.g. JWS and our LWS), usually
> use
> >>a file servlet to handle requests for static files like HTML and images. A
> >>call like getRequestDispatcher("/foo.html") goes through the normal
> >>path-to-servlet mapping and an RD for the file servlet is returned. So in
> this
> >>case it works fine.
> >>
> >>Add-ons on the other had are usually set up to only handle servlet requests
> >>and don't have a corresponding file servlet to serve static files; the web
> >>server takes care of static files without involving the servlet engine.
> >>So here a call to getRequestDispatcher("/foo.html") typically returns null.
> >>
> >>Even an add-on can of course include a file servlet to handle exactly this
> >>situation, but then it (may) bypass the web server's ACL controls. It could
> >>also handle this situation with a special RD that uses a URLConnection back
> >>to the web server, but again this may compromise security since the request
> >>to the web server now comes from the servlet engine instead of the real user.
> >>
> >>Is this security problem a big deal? Well for some it probably is but as
> >>long as a servlet can open a file directly using a File object and a path
> >>returned from SerlvetContext.getRealPath(), including a file servlet in
> >>an add-on engine doesn't compromise security more than it already is.
> >>So asking add-on engine vendors to do this may be the easiest way to get
> >>consistent behavior.
> >>
> >>As you can see it's a tricky situation. I would love to hear what others
> >>feel about this.
> >>
> >>--
> >>Hans Bergsten [EMAIL PROTECTED]
> >>Gefion Software http://www.gefionsoftware.com
> >>
> >>===========================================================================
> >>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> >>of the message "signoff JSP-INTEREST". For general help, send email to
> >>[EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
> >--
> >Jason Puyleart
> >Internet Concepts, LLC
> >[EMAIL PROTECTED]
> >Office: 608.285.6600
> >Fax: 608.285.6601
> >
> >___________________________________________________________________________
> >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
>
> ___________________________________________________________________________
> 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
___________________________________________________________________________
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
