Hey Luca: Stanley thinks he messed up, but if you ignore the fact that he thought it was an SSL tunneling problem, he actually exposed a real, albeit never-before-seen problem with ntop.
When you pass a request through a proxy server (something users might be doing without ever realizing it), it's LEGAL for the proxy to rewrite the request in a way such that ntop's URLsecurity will reject it. The request: GET /index.html HTTP/1.1 for example could become GET http://tigger.burtonstrauss.us:3000/index.html HTTP/1.1 (I suppose this is so that the remote server can handle a virtual request without requiring the usual Host: header...) But it's legal - read RFC1945, section 5.1.2 Request-URI for the "absoluteURI" stuff. URLsecurity sees the // and rejects the request. Quite properly, except for this special case. Before we realized what the real issue was, I'd written a hack-around the special case patch, which turns out to be the right thing for the (obscure) general case. Unless you've got issues with this, I'm going to 1) Apply it and 2) Give poor Stanley full credit for finding the Most-obscure-right-there-in-your-face bug so far this year. -----Burton PS: S - I'm not mad, I'm actually pleased that it was 1) not a major bug and 2) so much fun to chase down... _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
