Thanks to Vince and ServletExec once again! I'm looking forward to seeing
the specification!
At 07:51 PM 4/12/99 -0400, you 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
--
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
