Change Details

The /known endpoint takes as input a list of PIDs. To avoid abusing the DB backend (no matter how much data the web server will accept) we should put a limit on how many PIDs are accepted. There should be a default, and it should be overridable at the webapp configuration level. A reasonable default to begin with is probably 1'000 PIDs (one PID is 50 character long, so that's about 50 KiB + json list terminators). I'm not sure if the limit can be verified in a streaming way, without having to fully load the list in memory first, but it would be nice to, to avoid OOMs. cc: @anlambert for reviewing that part when we have a fix

The /known endpoint takes as input a list of PIDs. To avoid abusing the DB backend (no matter how much data the web server will accept) we should put a limit on how many PIDs are accepted. There should be a default, and it should be overridable at the webapp configuration level. A reasonable default to begin with is probably 1'000 PIDs (one PID is 50 character long, so that's about 50 KiB + json list terminators). (no need to check the limit in a streaming fashion, we will delegate that part to varnish: T2277)

The /known endpoint takes as input a list of PIDs. To avoid abusing the DB backend (no matter how much data the web server will accept) we should put a limit on how many PIDs are accepted. There should be a default, and it should be overridable at the webapp configuration level. A reasonable default to begin with is probably 1'000 PIDs (one PID is 50 character long, so that's about 50 KiB + json list terminators). I'm not sure if the limit can be verified in a streaming way, without having to fully load the list in memory first, but it would be nice to(no need to check the limit in a streaming fashion, to avoid OOMs. cc: @anlambert for reviewingwe will delegate that part when we have a fixto varnish: T2277)