bug: res:json() is nil

[whatwewant]

https://github.com/tokers/lua-resty-requests/blob/ff1309a4882a8253df18d6a37985f004aec3f8a1/lib/resty/requests/response.lua#L315 https://github.com/tokers/lua-resty-requests/blob/ff1309a4882a8253df18d6a37985f004aec3f8a1/lib/resty/requests/response.lua#L316

I found the bug is caused by the code, fixed ContentType values, it should using regular expression to detect the validity of ContentType

[tokers]

@whatwewant Maybe I didn't catch your mean. Could you provide some cases to show me the problem? It seems good to me for the detection of Content-Type, is there any provision about the value of Content-Type?

[whatwewant]

Some servers provide Content-Type: application/json;charset=utf-8, such as coding.net some apis, this will caused json() == nil

[whatwewant]

and another, i think it better to validate two thing here

1. json type
2. charset

[tokers]

@whatwewant Actually I wanna keep it consistent with Python requests library. I have glanced requests' source code, it guessing the encoding way of content and decoding it. So maybe we can try to decode
the content too. Would you like to submit a PR to optimize this? Thanks!

[whatwewant]

Well, I see. this issue is to solve json first. I also found pythons requests parses json at https://github.com/psf/requests/blob/eedd67462819f8dbf8c1c32e77f9070606605231/requests/models.py#L921 . Only try to parse data ~~ That may be not better, but it is more compatible for something like this issue, because some old services is not reponse according standard.

[whatwewant]

About encoding, I will try to make it solved like python.

[whatwewant]

I also see json parse method do the same as python requests in node-fetch(https://github.com/bitinn/node-fetch/blob/8c197f8982a238b3c345c64b17bfa92e16b4f7c4/src/body.js#L119) and axios(https://github.com/axios/axios/blob/1b07fb9365d38a1a8ce7427130bf9db8101daf09/lib/defaults.js#L61) Also in go grequests, the json parse method is not decide by Content Type. I agree you want to do better with response context-type indeed, but maybe the common solution is more compatible.