Re: AJP13 successor : Was: [Fwd: DoS Attack on Apache/Tomcat Servers]

[Bill Barker <wb...@wilshire.com>]

Urm, err, could we please switch this over to tomcat-dev?  We've gone beyond
the (non-)security problem, so now you are just messing with my
message-filter-rules.

Since there is nothing security-sensitive in the below, I'm cc-ing
tomcat-dev, and I hope that the rest of this will stay there.

----- Original Message -----
From: "Henri Gomez" <hg...@apache.org>
To: "Costin Manolache" <co...@covalent.net>
Cc: "Bill Barker" <wb...@wilshire.com>; "Remy Maucherat"
<re...@apache.org>; <jf...@fujitsu-siemens.com>; "Costin Manolache"
<co...@covalent.net>; "Ignacio J. Ortega" <na...@siapi.es>;
<mt...@mappingsoft.com>
Sent: Tuesday, November 26, 2002 1:18 AM
Subject: Re: AJP13 successor : Was: [Fwd: DoS Attack on Apache/Tomcat
Servers]


>
> > The response body is binary and can be used in any way.
> > The headers can also be made useful ( nothing requires them to
> > be http headers ).
>
> the problem is there is STILL no headers in replies, yet a miss in
> ajp13 protocol.
>
> > People are using HTTP as a general-purpose protocol in countless
> > projects, and ajp13 is just a binary form of http. You can put
> > _anything_ on top of it.
> >
> > And if you put all the features on _top_ of the protocol - you can later
> > use any other protocol - without changing anything in the feature impl.
> > If the data structures are simple, you can use XDR/RPC, IIOP/Corba, RMI
> > or SOAP or anything else.
>
> I agree but you should put some sort of reservation on protocol to make
> distingo between DATA and COMMANDS and that's not the case in ajp13.
>
> >>I don't want to add this to ajp13, but to ajp13++, ajp14, whatever name
> >>we agree on.
> >
> > I don't want to add this to ajp13 either - I think ajp13 as a wire
> > protocol should be frozen. Adding it on top of ajp13 is a different
> > issue ( i.e. use the ajp13 binary protocol for transport and
> > encapsulation, with special URIs and messages ).
>
> ajp13 is a wire protocol but there is some miss like indicating if
> there is a body request to follow, dito for the reply side, where it
> would be usefull to have for example a sort of reply header.
>
> > Admin stuff is not performance critical - a lot can be implemented
> > using regular servlets ( on the java side ). For auth - all you need
> > is a "authenticated" flag on mod_jk and jk/java side ( I think the
> > code is already there for jk2 ), and a config piece to set the
> > password. The "special" request will call a handler ( or servlet ),
> > and that would set the flag for the connection.
> >
> >>The idea is to make the java side simpler by avoiding to decode HTTP/1.1
> >>headers to know if there is body to came. The request forwarding code in
> >>ajp13 is really a plate of spaghetti, at least in jk 1.2.1, and I feel
> >>it should be the same in jk2.
> >
> > The problem with the body is a bit different - the second packet with
> > the initial chunk is badly encapsulated ( no 'type' ).
> > There is some associated complexity - but not that much. Most of
> > the spaghetti is the result of recovering and lb work.
>
> that's what I said previously.
>
> > Cleaning up the code and refactoring shouldn't depend on the details of
> > the protocol or on new features. I'm always +1 on refactoring :-)
>
> I'm +1 to refactor what could be, but I'm more reserved when time arrive
> to de-spaghetise pretty old code (even if I added my part in the
recovery).
>
> >>Ok, I've got no problem on using existing standard for the new protocol,
> >>XDR, Mozilla COM or whatever we all find a real interest will be fine,
> >>but the idea is to freeze ajp13 and start a protocol which will goes
> >>farther than just request forwarding.
> >
> >
> > +1 - ajp13 should be considered frozen. What I'm saying is that a lot
> > of features can be added on top of the existing protocol ( using ajp13
> > for request forwarding only ). If a different protocol is developed in
> > parallel - that's a different story.
>
> That's exactly what I propose, starting a new protocol !
>
> >>I'm waiting for URLs and references, so we could have a good starting
> >>point before making request/proposal on tomcat-dev.
> >
> >
> > XDR is RFC1014
>
> Read it, XDR define an encoding which is similar to the one used
> in ajp13 (well ajp13 as a subset), so it could cover the encoding side
> of the protocol.
>
> > Mozilla Blackwood:
> >   http://www.mozilla.org/projects/blackwood/
>
> This one make me think at a sort of JNI/RMI, but what could we do
> with it ?
>
> > KDE java protocol:
> >
> >
http://developer.kde.org/documentation/library/kdeqt/kde2arch/kdejava-archit
ecture.html
>
> Insteresting but the documentation didn't give much details on
> underlying protocol.
>
> > IMO XDR would be the best choice for marshaling.
>
> It's very close to ajp13.
>
> >>>Speaking of problems with the ajp13 - having a "fixed" protocol instead
> >>>of a generic RPC-like is IMO the biggest problem. The protocol has no
> >>>reason to know about what kind of methods or packet it is sending.
> >>
> >>So we agree on this point.
> >
> >
> > I'm not sure, but I hope so.
>
> My idea in making a new protocol between native and java side was to
> bundled in webserver a new kind of RPC between native and java side.
> The idea behind was to make it ready to use HTTP of course but
> also any java application, as sort of reminiscence of mod_java.
>
> A little as Sam does with the Java PHP extension
> (http://www.php.net/manual/en/ref.java.php), but allowing REMOTE JVM.
>
> > My point is that all features should be implemented on RPC level, as API
> > calls, independent of the low-level protocol. Ajp13 requests/responses
> > are as good as any other message format, and we have most of the code
> > working and tested and widely deployed.
>
> ajp13 req/res are well known but too HTTP oriented.
>
> >>Yes, but how slow it will be. There is 2 possibilities here :
> >
> > I'm not suggesting using soap, of course. Custom protocols can be
> > a bit faster for very specific tasks, but become complex and slower
> > if you want to scale them to more functions. Generic RPC protocols
> > are usually cleaner ( at least IMO )
>
> zzz = call(aa,bb,cc) is the way it should be done, coding is in a
> protocol should be easy, some calls being HTTP Request :
>
> zzz = Get(Request, Reply)
>
> Others being just non HTTP related.
>
> >>- use a new ajp protocol, which will hide HTTP protocol to tomcat and
> >>   being JMXizable.
> >
> >
> > Again - the protocol has nothing to do with what you implement on top
> > of the protocol. GET/SET can be implemented on top of anything.
>
> zzz = GetJMX(myprop)
> setJMX(anotherProp, PropValue)
>
> >>- or now that HTTP/1.1 connector is so fast, just make extension
> >>   to mod_proxy to support load-balancing.
> >
> >
> > That's a valid approach, and it can be combined very well with the
> > implementation of the additional methods on top of ajp13 req/response.
> > ( in other words - admin commands via HTTP/1.1 will probably be
> > identical with the admin commands via ajp13 special requests ).
> >
> > Since we already have the code to parse name/value pair - using
> > it in the body with trivial servlets ( or handlers ) would be the
> > easiest solution ( for config - where performance is not critical ).
> >
> >
> >
> >>>But let's keep things separated - exposing the getters/setters are
> >>>better done at a higher level, independent of the protocol !
> >>>( i.e. sort of RPC over ajp13 or the new protocol - they should be just
> >>>regular methods  )
> >>
> >>Warning, if we extend ajp13, it may break old java ajp13 implementations
> >>or alternate (ie jetty). And making use of pseudo URI to determine the
> >>level of ajp13 extensions handled by the java side isn't a clean way,
> >>it's still too HTTP related.
> >
> >
> > Why do you think it's not clean ? IMO it would be quite intuitive for
> > most web developers.
>
> The goal was to goes farther just HTTP, after all Apache 2.0 add support
> for non http protocol, ie POP3.
>
> >>>Regarding getters/setters/auth - I hope you agree on implementing them
> >>>at the higher level ( above protocol ), and let me try implementing
them
> >>>over ajp13 as well.
> >>
> >>A new protocol good have entries to support getters/setters/auth
> >>directly, ajp13 could do it by specials URI, and JNI by others direct
calls.
> >
> >
> > I disagree here. The protocol shouldn't care about getters or setters.
> > Maybe about auth - but in most cases auth is better implemented at a
> > higher level. Only encryption negotiation should be at protocol level
> > ( there is a common pattern for that - see SASL and similar approaches
> > used for LDAP, IMAP, etc ).
>
> Authentification SHOULD be part of the protocol, get/set being just RPC
> CALLS.
>
> >>>At the moment the biggest improvement ( IMO ) is avoiding the
duplicated
> >>>mapping - and that's unrelated to the protocol.
> >>
> >>Interesting feature, could the mapping be removed from Tomcat side if a
> >>request came from ajpxxx ?
> >
> >
> > AFAIK - it is (or was ) in 3.3 mapper ( i.e. don't do the mapping if the
> > servlet paths is set ). It's quite easy to add to 5.0, but we should
> > wait for the new mapper.
>
> That's your area, wait and see.
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>