Alan Williamson wrote:
>> Have you implemented a ReadFilter to throttle requests? Because inside
>> that class, you might just set:
>>
>> ctx.getSelectorHandler().getSelectionKeyHandler().cancel(ctx.getSelectionKey());
>
>
> i am about to implement that beast now!
>
>
>> If you are inside Adapter, try to do
>>
>> res.addHeader("Connection:","close");
>> res.setStatus(408); //Or 404
>
> This worked thanks. Although it still sent back data to the client;
> albiet just the header. No way to short cut that? just close the
> connection?
You gonna need to do it at the NIO level (inside the ProtocolFilter).
Unfortunately I've never needed to do it at the Adapter level...
>
> Speaking of closing connections:
>
> ByteBufferInputStream.setDefaultReadTimeout( 5000 );
>
> This doesn't work as i would hope it to. Try the following.
>
> telnet to your grizzly server. Then, once a second, fire off a single
> character, with CRLR. You will be able to do this until you are bored!
Hum then it's a bug. Stay tuned for the fix.
I suspect the connection will be dropped after 250 requests (the
st.setMaxKeepAliveRequests(...)....
>
> now try that to an Apache server, or even Google server. You will
> notice it kicks you out instantly because the first line of the HTTP
> request is invalid.
That is what is supposed to do actually.
>
> So this is a major DoS attack potential on a Grizzly server. Its
> usually the simple attacks that can really bring down a good server! :(
>
> What can we do to prevent this?
>
Fix the issue :-) Stay tuned!
-- Jeanfrancois
> thanks
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>