Instead it will always go through content_types_accepted and it is
up to the resource code to do any creation and to return the created
path if the method is POST and the client should be redirected to the
created resource's location.
This removes the meta value 'put_path' as it is not needed anymore.
This fixes an issue with PATCH where content types were not normalized.
This kind of function is highly dependent on the proxy used,
therefore parsing was added for x-forwarded-for instead and we
just let users write the function that works for them. The code
can be easily extracted if anyone was using the function.
This allows us to change the max chunk length on a per chunk basis
instead of for the whole stream. It's also much easier to use this
way even if we don't want to change the chunk size.
Defaults to a maximum of 1000000 bytes.
Also standardize the te_identity and te_chunked decoding functions.
Now they both try to read as much as possible (up to the limit),
making body reading much faster when not using chunked encoding.
For get_type_provided:
'*' will be match any parameters of media-range in "accept" header.
If '*' matched, then '*' is replaced by the matching parameters.
If Accept header is missing and '*' using, then in media_type in parameters
will be '*' and reply content-type will be without any parameters.
For content_types_accepted:
'*' will be match any parameters in "content-type" header.
If a loop handler sent a response (e.g. cowboy_req:chunked_reply/2,/3)
and then returns {loop, Req, HandlerState, hibernate} it
would have a {cowboy_req, resp_sent} message in its message queue. This
message would cause the process to immediately awaken, so it is flushed
before hibernation.
It is sometimes important to make a socket passive as it was initially
and as it is expected to be by cowboy_protocol, right after we've done
with loop handling.
