Sven Köhler wrote:
3. On top of regular request/response. Almost everything related with auth, pings, discovery, reconfiguration can be implemented by just using regular Ajp13 requests - with a special URL. That is by far my favorite mechanism. It also has the advantage that it can reuse other parts of tomcat - mapper, coyote actions, etc. I strongly believe that most features should be implemented at this layer ( regardless of the request message or the wire protocol changes )
special URLs are by far the best mechanism? the next simpson-episode should start with bart writing "special urls are by far the worst mechanism ever" to the board.
it's working around a missing feature - nothing more, nothing less. it's the worse method i could imagine.
your are talking about seomthing like /_ajp/config or somethin, right? what if this URL occurs within the users directory structure? using illegal URLs like _ajp/config could confuse other ajp-implementation that are not aware of such sh*t.
Old ajp implementations will just return the regular 404 or 500 - what else
would you want to happen ? To ignore the unknown messages and let the other
side believe all is ok ?
It can also use a AJP method ( instead of GET ). Again - a regular error
message will be returned.
And again, the confusion happens only if you use new features with old implementations. I think new features should be explicitedly turned on - or at least you should be able to turn them off if you know you are talking with an old version.
IMO this mechanism is far better than bloating the protocol - all experience we had in the last 3 years shows only few people are willing to mess with the C code and the lower layers. Higher level constructs are easier to maintain and debug than wire protocols.
I'm confortable with C code ;)
BTW, I think we should close this noisy thread and tell :
- ajp13 protocol didn't support 'gracefull' exit feature since we don't want to break old implementation.
A solution could be to set a worker option to make it enable, and send the wanted 'gracefull exit code' when will detect that the connection will be dropped.
It could be done, but I don't have time right now, so it will be in a future JK 1.2.3 release.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
