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
