Thanks
Currently HttpUtils does return (almost) the same response when it is
truncated.. so that the truncated version can later be included in the
ErrorResponse…
I would be OK with changing the error message to not include ANY of the
response, since either way it is an error message.
Then the error message would ONLY be:
"The action produced a response that exceeded the allowed length:
${length.toBytes} > ${maxLength.toBytes} bytes.”
Instead of
"The action produced a response that exceeded the allowed length:
${length.toBytes} > ${maxLength.toBytes} bytes. The truncated response was:
$trunk"
WDYT?
> On Jul 13, 2018, at 5:21 PM, Markus Thoemmes <[email protected]>
> wrote:
>
> Hi Tyson,
>
> Chetan solved a similar problem in "inlineOrAttach" in
> "AttachmentSupport.scala". He did this by continuously running a stream
> through "prefixAndTail", where he'd pick just one element and then run the
> stream to check whether he already crossed the limit.
>
> This case now is a lot more performance critical, so I propose we add a
> "prefixAndTailWeighted" stage, which runs similar to "prefixAndTail" but
> weighs the inputs by their siuze so you can define how much you actually want
> to consume in bytes. You can then run the "tail" stream to an ignore Sink.
> Further, I'd propose to implement a "quick path" (like there is on in the
> current HttpUtils), which checks the "Content-Length" field of the response
> and just consumes the whole stream into a string if it's safe to do so to
> only use this special method on the truncation path.
>
> As a more general, existential question: Do we even need the truncation path?
> Could we just deny the response straight away if the user's action returns a
> bigger value than allowed?
>
> Hope this helps
>
> Cheers,
> Markus
>
