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" <[EMAIL PROTECTED]> To: "Costin Manolache" <[EMAIL PROTECTED]> Cc: "Bill Barker" <[EMAIL PROTECTED]>; "Remy Maucherat" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Costin Manolache" <[EMAIL PROTECTED]>; "Ignacio J. Ortega" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
