It all depends on the details of the implementation , but eventually the proxy process needs to parse the json string and pass down to the function, the function as user write them don’t assume partial chunks
But I general I tend to agree with Markus on no hard limits if possible and let surrounding environment the limits if any. - Carlos Santana @csantanapr > On Sep 11, 2018, at 9:43 AM, Rodric Rabbah <[email protected]> wrote: > > I assume Michele is referring to a buffer to eventually hold the function’s > input (which is limited to 1MB by default though some deployments use 6MB) - > not a transient/intermediate buffer. We’ll see... > > -r > >> On Sep 11, 2018, at 6:30 AM, Markus Thömmes <[email protected]> >> wrote: >> >> Heya, >> >> I tend to agree with Felix. Buffers are usually just used as a transport >> mechanism and they shouldn't need to fit the whole response at once (which >> doesn't imply we don't load the response in memory, but at least that input >> buffer doesn't need to be == content-length). Could you give a bit more >> context on what the scan buffer does and why 64k isn't enough space to do >> what we need? >> >> Moreover, I'd rather not set any hard limits on the runtimes themselves. >> The limits should be imposed by the surrounding system, the user-containers >> could accept however much payload as they can fit. That reduces the amount >> of configuration and testing needed. If we start imposing these limits on >> every layer, we'll need to test every layer to correctly impose the limits. >> >> Cheers, >> Markus >> >> Am Di., 11. Sep. 2018 um 15:08 Uhr schrieb Felix Meschberger >> <[email protected]>: >> >>> Hi >>> >>> Holding the complete input in memory ? Sounds like a good DoS surface - >>> unless you limit the input size.... >>> >>> Regards >>> Felix >>> >>> -- >>> Creative typing support courtesy of my iPhone >>> >>> Am 11.09.2018 um 15:02 schrieb Rodric Rabbah <[email protected]<mailto: >>> [email protected]>>: >>> >>> The http post will have a content length is that useful? >>> >>> -r >>> >>> On Sep 10, 2018, at 7:45 AM, Michele Sciabarra <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hello, I am in the process of running the mandatory tests against the Go >>> Runtime. >>> In the process, I fixed a lot of bugs, because those tests revealed a >>> number of details about encoding, env variables and other things that were >>> not obvious to me in the first place. >>> >>> Now I have a problem: I am trying to pass the test that tried to send a >>> one-megabyte big request to the runtime. >>> Currently, it does not work because I discovered the "scan" buffer has in >>> Golang a fixed size of 64k. >>> >>> Of course, I can increase it but I need to know how big it must be. I know >>> that you can set some parameters at OpenWhisk level but I am not aware how >>> a runtime can know those parameters. Most notably I need to be able to read >>> the maximum size of the requests because I need to allocate a buffer at >>> init time. Any hints? >>> >>> >>> -- >>> Michele Sciabarra >>> [email protected]<mailto:[email protected]> >>>
