A browser can tell the server explicitly which encoding is used thanks to Content-type
header. Content-type
might contains charset
, but it's possible to infer the encoding by type. For example, application/json
:
Content-type: application/json; charset=utf-8 designates the content
to be in JSON format, encoded in the UTF-8 character encoding.
Designating the encoding is somewhat redundant for JSON, since the
default (only?) encoding for JSON is UTF-8. So in this case the
receiving server apparently is happy knowing that it's dealing with
JSON and assumes that the encoding is UTF-8 by default, that's why it
works with or without the header.
What about the situation that Content-type
is not defined in request?
A sender that generates a message containing a payload body SHOULD
generate a Content-Type header field in that message unless the
intended media type of the enclosed representation is unknown to the
sender. If a Content-Type header field is not present, the recipient
MAY either assume a media type of "application/octet-stream"
([RFC2046], Section 4.5.1) or examine the data to determine its type.