But we could add it for JSON, yes. And probably MessagePack, although I'm less convinced of that case.
For
Because I noticed some people swear by
JSONHandler, it would probably be good to add it regardless of the framework design we settle on.Because I noticed some people swear by
None, whereas others expect a {} (even though JSON does not strictly need to be a dict).
vytas7 @vytas7 is checking browser console :slight_smile:
the browser errors
I don't have a strong preference / a solution that I would feel is clearly the best :grimacing:
But my idea was that
JSONHandler could have the empty value option regardless of the remaining of the framework.
And (I'm less convinced myself...) the remaining of the framework could probably use your machinery to raise specialized missing body exceptions (?)
Getting back to the interesting discussion with @sisp btw.
Shall we reopen falconry/falcon#1499, add comments to the WSGI middleware issue, or create a new one?
Shall we reopen falconry/falcon#1499, add comments to the WSGI middleware issue, or create a new one?
31 replies
Because if a client submits a
multipart/form-data with a boundary parameter, and that boundary is not found in the payload, that is a bad request in my estimation.
empty body ->
len(body) == 0
still it could use an option regarding what to do when an empty body is encountered
I actually like better the option to set that parameter in the media hander instead of each time we call
get_media
(I'm not sure these are actually called prologue and epilogue in this context. But you get the idea: https://ec.haxx.se/http/http-multipart#the-http-this-generates )
(The example form begins with
--------------------------d74496d66958873e, and ends with --------------------------d74496d66958873e--).
Are escape rules still needed even in the current spec?
As noted in Section 5.1
of [RFC2046], the boundary delimiter MUST NOT appear inside any of
the encapsulated parts, and it is often necessary to enclose the
"boundary" parameter values in quotes in the Content-Type header
field.
Given the right algorithm, finding a long substring in a long string is actually very fast.
We rely on Python's
in and .find(), with the exception of one pure-Cython hack in the cythonized version.
usually throwing more hw at the problem solves it
Sad but true too :slight_smile:
like don't roll your own double for that is O(n*m)