Dave Pawson wrote:
Rob, Christopher, Andre.
Thanks for the input.
As I said to Rob, security is not an issue at the present time.
There is no value in the content returned by the 'server' / end point;
I'm not trying to make it secure. Just respond less than
I otherwise might.
Ok, then let me make one final guess and suggestion.
If the point is just for your server application to avoid wasting time
sending a response to a client that is not "yours", and which would not
be able to do something useful with it anyway, then the easiest route
would probably still be a simple "servlet filter".
That servlet filter would examine the request headers (say the
"User-Agent" header, which your client would set appropriately),
determine if it is or not the appropriate client, and if not send an
appropriate HTTP 4xx error response right away, without even letting the
request go to the servlet or restlet or whatever.
By sending the correct 4xx kind of response, you would let this "client"
know right away, without a doubt, that there is no content here for him,
and that he should not even retry, thus avoiding further waste of time
for everyone. Google for "HTTP response codes" to find the most
appropriate response in your case.
You may even find a ready-made servlet filter that could do that (and
many other things besides) here :
http://www.tuckey.org/urlrewrite/
A servlet filter does not modify (or require you to modify) the
application in any way; it just sees the request before your application
does, and can do something to it before the application sees it; it also
sees the response of your application after it is produced and can do
something to it before it is passed to the client.
Also, servlet filters are an entirely portable mechanism, defined in the
Servlet Specification, so this would work on any servlet engine.
Note again that the above is not in any way a security mechanism,
because any client can send whatever User-Agent header it very well
pleases. But it would be a very HTTP RFC-compliant way of kindly asking
inappropriate clients to just go away and not come back.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
