BTW, trying prefixAndTail, this doesn’t work for me
e.g.
response.entity.dataBytes
.prefixAndTail(1)
.runWith(Sink.head)
.map({
case (Seq(r), _) =>
Right(ContainerResponse(response.status.intValue, r.utf8String,
Some(contentLength.B, maxResponse)))
})
Does not result with r.size==1, rather r.size == response.entity.size
I will try to fiddle with it some more(and ignore the tail)
> On Jul 13, 2018, at 5:29 PM, Tyson Norris <[email protected]> wrote:
>
> 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
>>
>
