<div class="gmail_quote">On Thu, Jan 19, 2012 at 8:06 PM, Ivan Kozik <span dir="ltr"><<a href="mailto:ivan@ludios.org">ivan@ludios.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
No, I wasn't happy with termination. I wanted to treat it just like a<br>
JSON decoding error, and send the appropriate response.<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I actually forgot to mention the main reason I abandoned the<br>
stop-at-N-collisions approach. I had a server with a dict that stayed<br>
in memory, across many requests. It was being populated with<br>
identifiers chosen by clients. I couldn't have my server stay broken<br>
if this dict filled up with a bunch of colliding keys. (I don't think<br>
I could have done another thing either, like nuke the dict or evict<br>
some keys.)<br></blockquote><div><br>What would your service do if it ran out of memory?<br><br>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:".) <br>
</div></div><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)<br>