(original) (raw)
On Thu, Jan 19, 2012 at 8:06 PM, Ivan Kozik <ivan@ludios.org> wrote:
So was this attack actually being mounted on your service regularly? I'd think it would be sufficient to treat it as a MemoryError -- unavoidable, if it happens things are really bad, and hopefully you'll crash quickly and some monitor process restarts your service. That's a mechanism that you should have anyway.
What would your service do if it ran out of memory?
Maybe one tweak to the collision counting would be that the exception needs to inherit from BaseException (like MemoryError) so most generic exception handlers don't actually handle it. (Style note: never use "except:", always use "except Exception:".)
No, I wasn't happy with termination. �I wanted to treat it just like a
JSON decoding error, and send the appropriate response.
So was this attack actually being mounted on your service regularly? I'd think it would be sufficient to treat it as a MemoryError -- unavoidable, if it happens things are really bad, and hopefully you'll crash quickly and some monitor process restarts your service. That's a mechanism that you should have anyway.
�
I actually forgot to mention the main reason I abandoned the
stop-at-N-collisions approach. �I had a server with a dict that stayed
in memory, across many requests. �It was being populated with
identifiers chosen by clients. �I couldn't have my server stay broken
if this dict filled up with a bunch of colliding keys. �(I don't think
I could have done another thing either, like nuke the dict or evict
some keys.)
What would your service do if it ran out of memory?
Maybe one tweak to the collision counting would be that the exception needs to inherit from BaseException (like MemoryError) so most generic exception handlers don't actually handle it. (Style note: never use "except:", always use "except Exception:".)
--
--Guido van Rossum (python.org/\~guido)