Random headers lead to memory exaust.

[riktam]

Hi,
I'm using a web API in which the developers decided to add one randomly named header to every response.
Since the headers are interned in the keyword package, after a few hundreds thousand of calls both SBCL and CCL run out of (immobile) space where the symbols are stored.

Would you be willing to change the code to support strings instead of, or in parallel with symbols as header keys implementation?

[vindarel]

As a workaround, to my knowledge the other library doesn't have this issue (dexador).

[stassats]

A pull request that adds a variable controlling how the headers are parsed would be fine. Common headers should probably still remain as keywords.

[adlai]

I believe the leak is plugged by edicl/chunga@c29d92e although this Issue could remain open to encourage a more sophisticated solution.

[adlai]

Copying my comment from the similar issue edicl/hunchentoot#24:

...it would be gracious towards applications that use non-standard headers if Chunga modifies known-words.lisp to support modification of the known word cache, although it should probably be wrapped in an API that modifies both tables rather than letting library users accidentally get them inconsistent.

I'm imagining a usage where apps that rely on custom headers populate the caches at startup, and they remain relatively unchanged while the application runs. Defining them as constants might hinder this, depending on how the compiler interprets the constant declaration on a hashtable.