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
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
