-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
All,
bump
It's hard to see anything with all the commit messages :)
On 5/9/19 12:52, Christopher Schultz wrote:
> All,
>
> What are the options we might have to "punish" an HTTP client that
> we don't like for some reason?
>
> Specifically, I'd like to be able to write a servlet that ties-up
> the response to the client for a while for some bad behavior. For
> example, maybe lots of authentication attempts or some other
> criteria. Maybe even just a single bad authentication attempt.
>
> I'm thinking of something along these lines:
>
> public void doGet(...) {
>
> ...
>
> if(shouldPunishClient(...)) { request.setAttribute("delay-client",
> Boolean.TRUE); return; }
>
> ... }
>
> Or maybe even specify a time-out.
>
> Then, Tomcat observes that the servlet or filter wants to put the
> response into the penalty box and, instead of flushing the
> response and (possibly) closing the connection, it just sits-around
> for a while, keeping the connection open.
>
> The poller usually waits for data to become available on either end
> of the connection and pushes the bytes. How complicated would it be
> to put connections into a queue where they wait some amount of
> time before being flushed/closed/returned to the connection pool?
> In this case, the only stimulus for taking action is the passage of
> time, not arrival of data on a stream.
>
> Any thoughts about how this could be done?
>
> Clearly, a simple Thread.sleep() would do the trick in terms of
> just making the client wait, but the point would be to make the
> client wait without a performance impact on the server.
>
> -chris
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzbE9wACgkQHPApP6U8
pFi/Ew/9FxbZMlSr0OZPlh8g7dbQa8tGbvXJD+zRo27dW15oYtUkA4S3nWjhR67S
90T4N4uH+BmKMfHJwVC+Kp7LjFa9GP5g6sLAdJcnZSgriURkY+3f5UIO42GDjaCg
Wxm1UjnD/DuYMlW1M/HsyJZ9ps6+0X6vtZwJtBzxJJC+66WDOuI0SefnCJ0Gavbi
Or1julT0JT3oOuQYOk7mVgBL92jVOvACkQGAgCg4nnIpcXiyM8g0G/J9qLKSE4n+
S6wdTNaYkOlJ9vgCqTbx/8HkjHdNV0Riif+jqYG8vFvETvP6W87MfutBbiV1tZUR
Z/Cno494WADV24VU22hbxax8YF7HYCMASeUoZoP1fcSsgJ/HbVVftV2AKcbDJ7QO
6ktUXsbh+hVNUZaxQ1Z4KW2sRrmlAKQ0Cdr/dSRRuKCTEuA2wGZmDSSQrvRtz+ND
McVw183m6V0aKnzBQXnrq7UJ/iO5G+UquBTtrQHT7mo9Zf24Sdj20d29te23B2Fi
ODl4P0I4b0ROXoBElLjHAQHjCizbMMStnzR9/d5LJQmjnP1RlBVpHUxpBEglTIrR
pheqvHoWFJ/glWdzB34TzLzX3nnBuax/+ZyIlvEkZSeeLws+5PE49riGYB9+CZO/
9xzykbJKcl5rEOW6tU2TDCyc4jiADMptIkWjpt0JovZXAma6vCo=
=eE5w
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]