Http Response Parser

WebRequest() hands back a status code, a raw header block and a body, but everything inside that header block stays one undifferentiated string. Individual header values, any Set-Cookie lines, and whether the body still needs de-chunking are all left as the caller's problem. Nearly every EA that talks to a REST API ends up writing its own small string parser for this from scratch, usually built from a few StringFind calls that break the moment a server sends headers in a different order, wraps a value in extra whitespace, or sends a cookie with an embedded semicolon. This library does that parsing once, correctly, and returns the result as a structured HttpResponse: numeric status code and text, HTTP version, an array of name/value headers, extracted cookie name/value pairs, and the body with chunked transfer-encoding already decoded if present. Two entry points cover the two shapes this data actually arrives in. HttpParseRaw takes a complete raw response - status line, CRLF-separated headers, a blank line, then the body - the shape you get from a captured log or a hand-built HTTP client. HttpParseHeadersOnly is fitted to WebRequest's actual signature: WebRequest returns the HTTP status code as its own int result and puts the header block (with no status line at all) into a separate result_headers string parameter, so this entry point takes those two pieces directly instead of forcing a caller to reassemble a fake raw response just to reuse the same parser. Chunked transfer-encoding is decoded properly rather than assumed away: each chunk is a hex size line, the chunk's data, and a trailing CRLF, repeated until a zero-size chunk terminates the stream (RFC 7230 4.1). Chunk sizes are read with a dedicated hex parser, not StringToInteger, which reads decimal and would silently misparse "1a" as the number 1. Header names are compared case-insensitively throughout, because HTTP defines header names as case-insensitive and a server sending "content-type" instead of "Content-Type" is not sending a different header - naive StringFind-based parsers routinely get this wrong. Header storage is a dynamic array of a small fixed-field struct (HttpHeader: two strings) rather than a 2D string array. Both MQL4 and MQL5 only allow the leftmost dimension of a 2D array to be dynamic, so a genuinely dynamic list of name/value pairs is expressed as a struct array instead - just as easy to iterate, with no ragged-array workaround needed, on either platform. Notes and limitations - HttpGetCookie exposes only the cookie's name and value. Attributes (Path, Expires, HttpOnly, Secure, SameSite) are discarded after the first semicolon - this is a value extractor, not a full cookie jar tracking expiry or scope. - HttpGetHeader returns the FIRST matching header. A server that legally repeats a header other than Set-Cookie will have its later values ignored by this function; iterate response.headers directly if you need every occurrence. - Chunk extensions (the rarely-used ";name=value" suffix on a chunk-size line) are recognised and skipped, not parsed into their own fields. - This library only parses text already delivered by WebRequest (or a string you supply). It makes no network calls itself and has no dependency on WebRequest being whitelisted for the demo to run.

Script · MT5 · v1.0 · Free

Tags: MT5 Script · MQL5 Source Code

MQL4 & MQL5 scripts · PolyMaria