A few ideas: options.extendTypes.custom, options.handler, split buffer thingy?
tunnckoCore opened this issue · comments
Get an ideas.
split buffer thingy
Currently (in v2.0):
- if you wanna buffer body, you should pass
options.buffer: true
and trick the things throughoptions.extendTypes.text
(because that's the only way to use thethis.request.buffer
parser to parse buffers). you will receive it inthis.request.body
- If you wanna limit the buffer size you should pass
options.textLimit
oroptions.bufferLimit
I'm asking myself, isn't it will be better if there's separate if
for options.extendTypes.buffer
and try to parse it separate from text? So i came to the next idea for extendTypes.custom
options.extendTypes.custom and options.handler
So, to be able hack the things legally. Meaning if you wanna parse foo/bar-x
type, for instance, you will pass that type to options.extendTypes.custom: ['foo/bar-x']
, then options.handler.call(ctx, ctx, options, next)
will be called.
This will give you the freedom and ability to do whatever you want:
- access the
this
context (ctx
) - access the original options (
options
) - to use all of the parsers -
ctx.request.json
,ctx.request.urlencoded
,ctx.request.multipart
,ctx.request.text
andctx.request.buffer
- and what your mind can think
@codeinvain, @ztrange, @LaurensRietveld, @internalfx, @creeperyang and @daiwhea, thoughts?
It sounds cool!
On an unrelated matter, since you stopped using this.body, I think the major version (semver) should be bumped, since it is a breaking change.
@ztrange I agree.
@tunnckoCore I think these are great additions. However, they are very likely to break existing apps.
@ztrange, i'm not sure enough. in one side, it is bugfix to wrong behaviour - it was total mistake, in another yea it is breaking change, but dont thinking for major bump, but for minor definitely.
about the ideas, i'll try to push them today.
but yea maybe you are right, i'll add these features and bump major directly
All is implemented as suggested.