>I agree that some form of authentication (and possibly
>encryption) are high-priority things to add to mod_jk / ajp13.
> Before I dive into that work, though, I want to be sure that
>there is a future for the code -- that's why I'm proposing
>using it in TC 4 as well as TC 3.
>Fortunately, the ACL's should be implementable without
>touching the packet types (I think you suggested this, Henri).
> We can just add a list of safe hosts to the configuration
>directives for TC, and it will only allow connections if they
>come from the specified hosts. I think this would still leave
>us open to IP address spoofing, but it would certainly be an
>improvement over what we've got now.
Yes something before the packet decoding. Like the host.allow/host.deny
found on Linux Boxes.
>For encryption, we would have to introduce new packet types.
>Personally, my feeling is that encryption of the stream
>between the Web Server and TC is much less important than
>authenticating connections. Especially given that SSH tunnels
>are not that hard to set up, I am reluctant to add the
>complexity of crypto code to ajp13.
May be we could find a not so hog crypto code.
>Finally, going ahead. I think it would be a good idea to
>introduce ajp14 (once the bulk of the work above has been
>completed). I would propose it as a slight variant on ajp13.
>Basically, the same protocol, with a few new packet types (we
>need something to handle > 8K of header information), *and*
>with provision for handling unknown packet types more
>intelligently. I think this would give us a protocol which we
>could live with more easily over time. We could add new
>features, but it could still communicate with old web server
>plugin versions.
+1
Only keep ajp13 for backward compatibily ?
