12-18-2018, 12:50 AM
(This post was last modified: 12-18-2018, 12:54 AM by thijsvandien.)
I do understand reasonably much about HTTP, but not how TIdHTTP abstracts over that. In particular, I did (or still do) not understand if/when Indy infers encodings, how it does so (e.g. looking at the headers of a request/response or at the data), if/when it does conversions or merely "advertises" the encoding (e.g. in the headers). I now dived a bit more into the code.
From what you are saying, I get that for methods use a TStream for the request body, Indy takes those bytes as-is. Then is any charset ever put in the headers automatically? If so, from where?
For responses, Indy will either write them as-is to the given TStream, or (using another overload) use ReadStringAsCharset decode them to String based on the charset provided in the headers or HTTP's default of ISO-8859-1 in case none is specified. Only if the content type is XML does it ignore all that and look at the actual data. Apart from that it does not look at content types to determine whether the response should be decoded at all (i.e. considered text) or not (i.e. considered binary). Correct?
From what you are saying, I get that for methods use a TStream for the request body, Indy takes those bytes as-is. Then is any charset ever put in the headers automatically? If so, from where?
For responses, Indy will either write them as-is to the given TStream, or (using another overload) use ReadStringAsCharset decode them to String based on the charset provided in the headers or HTTP's default of ISO-8859-1 in case none is specified. Only if the content type is XML does it ignore all that and look at the actual data. Apart from that it does not look at content types to determine whether the response should be decoded at all (i.e. considered text) or not (i.e. considered binary). Correct?