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 <markus.thoem...@de.ibm.com> 
> 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
> 

Reply via email to