> On Jan 16, 2015, at 10:38 AM, Christopher Schultz 
> <ch...@christopherschultz.net> wrote:
> 
>> This is for a license check phone-home server. Old versions of our
>> products had bugs that could cause them to endlessly make
>> phone-home requests as fast as possible. We need to examine the
>> POST data, check the product code parameter to see which product it
>> is, as well as a version parameter to see which version of the
>> product it is. We then consult a lookup table (hard-coded into
>> Java) to see whether to reject the request or respond to it.
>> 
>> I would assume that is beyond the scope of configurable filters in
>> Apache, maybe I’m wrong?
> 
> Apache httpd 2.4 has Lua built right into it. Perhaps you could
> knock-up a "filter" using that?
> 
> Does your product not set a User-Agent header with a version number
> when phoning-home? Perhaps you should start doing that, then you could
> filter based upon HTTP headers instead of part of the message body.
> 
> Another thing you might be able to do would be to have Apache httpd
> pull-out the data from the request body and pop it into a header,
> which Tomcat could check without processing the body. Something is
> still examining the body, but it will make your Java code simpler.

Thank you for the suggestion Christopher, that definitely makes sense.

Fortunately, I was able to come up with a different solution last night - the 
product (even old ones) have a frequency setting that I forgot about that can 
be used to limit how often they make requests. I originally designed it as a 
single server-wide setting for all clients to adjust overall server bandwidth, 
but by detecting the old buggy clients and sending them an Integer.MAX_VALUE 
for that frequency, I am able to effectively disable them. This has solved my 
problem.

--Jesse Barnum, President, 360Works
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to