As far as native libraries; I'd suggest WinINET over WinHTTP. Its a superset of WinHTTP but is scoped to the window user's profile, where as WinHTTP is not. WinHTTP is meant for services or similar that may need to run as a super user/admin
With that said, both WinHTTP and WinINET provide full support of the HTTP/1.1 standard, with a few 'ease of use' abstractions such as for ssl(HTTPS) requests, auto (de)compression of gzip, PAK and various others, and local caching.
--
As far as feed back:
1: Neither method of performing an HTTP request should use client-side caching unless its a subsequent 'session/keep-alive' request, or at the request of the scripter. I know WinHTTP/INET has a caching system, but cannot remember if its opt-in or opt-out.
2: Both methods should support specifying, at the least, a connection duration timeout. That is, if the connect remains open for longer than the specified duration it should be closed and an error raised.
3: If the abstraction includes redirect handling:
- There should be a way to opt-out of such
- There should be a switch to set a limit on the number of redirects to follow with a way to reset the 'count'
4: Synchronous connections should be immediately terminated if the user inputs the ctrl+break key combination.
5: Synchronous requests should result in an error if the body would exceed a (smallish) buffer-size limit:
- Users of slower internet speeds will experience varied freezing times for mIRC from large responses
- due to mIRC being a 32bit program, if the response is large enough its contents will, at the least, have to be wrote to a paging file thus resulting in slow access of the data.
Neither of which would make for a nice end-user experience.
6: Async HTTP requests should have events for:
- The request (headers and body) has finished being sent to the server; raised prior to any 'response' events
- When the full server head is received - making statuscode and headers available until the 'session' is closed
- Progressively as the body is received - making the portion of the body received since the previous firing accessible as both string or into a bvar
