On Fri, Jun 22, 2001 at 11:42:32AM +0100, Theodore Hong wrote: > I haven't looked at the servlet stuff, so I don't really have an opinion > about whether it belongs, but I did have some intentions to turn fproxy > into - not exactly a full web server, but a full proxy server. That is, > all your normal HTTP requests as well as your Freenet requests would pass > through fproxy. Then you would be able to catch anonymity-compromising > stuff better, and you could do more rewriting on Freenet URL's.
Simply accepting https connections instead of http could accomplish everything you want to accomplish w/r/to anonymity protection, because of the way web browsers treat https. > > OTOH, using servlets internally in fproxy to handle the HTTP requests > > (parsing the HTTP request options into the servlet options) is a > > different matter. If you did that, then the servlet part of fproxy could > > plug into apache and other servers that run serverlets, which might be > > useful - something that, unless I have misread the code gravely, could > > not work today because the internals of fproxy expect to find HTTP > > headers on the stream after the servlet is handled. That is internal to > > fproxy however, such a servlet structure should not be visible to Fred's > > core. > > That's another thought. However, I don't see how to reconcile this with an > internal interface between fproxy and Fred. Either they communicate > through shared memory, or they use sockets. If fproxy changes to use an > internal interface, it is obviously no longer usable as an Apache servlet, > unless you bring all of Fred into Apache as a servlet as well. (Although > that might be an interesting possibliity too - imagine if every Apache > webserver in the world came with Freenet by default.) fproxy is not usable as an apache servlet anyway. For this to be the case, it would have to subclass javax.servlet.http.HttpServlet, and it would need to implement service(HttpServletRequest req, HttpServletResponse resp). The current situation with fproxy, the xml-rpc servlet, and all the EOF servlets (I looked) is that they directly subclass GenericServlet (the class that is supposed to be subclassed by HttpServlet) and they implement service(ServletRequest req, ServletResponse resp) and then immediately cast the req and resp to FreenetServletRequest and FreenetServletResponse, which are literally nothing more than bloated wrappers around an InputStream and an OutputStream, respectively. *Then* they do the HTTP decoding (or whatever the relevant protocol is), even though this step is meant to occur _before_ service() is called. So basically, the servlet API in Fred is being completely misused. The reality is that fproxy, and all the other servlets that plug into Fred currently, ARE using an internal, nonstandard interface that is exactly equivalent to the 0.4 plugin API, except they add a lot of bloat and they don't pass the Node instance to the plug-in object. If people are really serious about wanting the servlets API in Fred, then we need to provide an implementation of javax.servlet.http.HttpServlet, as well as whatever servlet API is appropriate to other protocols (SMTP, NNTP, etc.) -- # tavin cole # # "Technology is a way of organizing the universe so that # man doesn't have to experience it." # # - Max Frisch _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
