Jesse Barnum wrote:
On Jan 14, 2015, at 12:29 AM, Konstantin Kolinko <knst.koli...@gmail.com> wrote:
2015-01-14 6:28 GMT+03:00 Christopher Schultz > Jesse,
On 1/13/15 6:29 PM, Jesse Barnum wrote:
I need the ability to examine the POST data from a request,
examine it, and either respond to it or close the connection
without returning any result, not even a 200 OK status.
The reason for this is because I’m getting overwhelmed with
thousands of invalid requests per second, which are racking up
bandwidth fees. The requests can’t be traced to an IP address, so I
can’t just block them in a firewall or Apache - I need to actually
use logic in my Tomcat app to figure out which requests to respond
to.
Is there a way to force Tomcat to just drop the connection and
close the socket without sending a response?
You can't close the stream form your code, Tomcat will ignore it, so a
response flush, and return a 200 response anyway.
I'm curious, what's wrong with an empty 200 response? It's only a
couple of bytes, but I suppose if you are getting millions per hous,
you could still incur bandwidth costs...
response.setHeader("Connection", "close") will cause Tomcat to close
the connection (i.e. do not use keep-alive that is default for
HTTP/1.1 requests).
Response body may be empty but by default the response includes HTTP
status code and reason phrase and some headers.
Is that too much?
You might be able to do this with a Valve, but then you might have
problems with your web application needing to provide the logic to
determine whether or not to accept the request.
It can be implemented in two tiers:
a) an application sets an attribute on request or uses some specific
status code on the response.
b) a valve detects presence of the attribute or status code and closes
the connection.
You have not mentioned your version of Tomcat.
For a pointer, note the following enum value in the source code
(available in the current 7.0.x, 8.0.x):
org.apache.coyote.ErrorState.CLOSE_NOW
org.apache.coyote.ErrorState.isIoAllowed()
Best regards,
Konstantin Kolinko
Thank you very much for all the help. After reading all of these responses, I
concluded that it was not that bad to just return an empty response, especially
by using mod_header to se the server and date headers to empty value.
I forgot to mention - I’m running Tomcat 7.052 with an Apache 2.2 front-end. I
have a feeling that even if I did implement the Valve trick, Apache would still
return some response to the user (likely an error 500 or 503 that the AJP
connector had failed to respond), so returning a very small response from
Tomcat is actually probably less outbound bandwidth.
If you do have an Apache httpd front-end anyway, it still seems a bit of a shame to have
to use any Tomcat bandwidth and resources in order to catch this kind of thing, and not be
able to do it at the Apache httpd level, before you even decide to proxy the request to
Tomcat. Apache httpd also has a lot of add-ons to catch and deny things like obstreperous
clients etc..
Are you sure that there is nothing which you could "export" from Tomcat to Apache httpd,
to allow httpd to catch these unwanted requests earlier ? (not necessarily all of them;
but whatever you catch there, saves resources in Tomcat).
Some info, if it can be useful : unlike a servlet or filter in Tomcat, Apache-based code
does not necessarily "consume" the whole request in order to examine for example some POST
parameters. So it can do that, and still proxy (or not) the whole request to Tomcat if
appropriate.
It is probably a fair bet, that many of these unwanted requests follow some kind of
general pattern that could be relatively easily filtered out early, isn't it ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
