Services and Tools

Inet HTTP Client

inet is NAppGUI's small cross-platform networking layer. In this checkout it is narrowly scoped: one HTTP client abstraction, explicit GET/POST helpers, simple whole-response download utilities, and a thin platform backend split across macOS, Windows, and Linux.

Relevant Source Files

src/inet/CMakeLists.txt src/inet/inet.h src/inet/inet.c src/inet/httpreq.h src/inet/httpreq.c src/inet/oshttpreq.inl src/inet/osx/oshttpreq.m src/inet/win/oshttpreq.c src/inet/linux/oshttpreq.c prj/NAppTarget.cmake prj/nappgui-config.cmake demo/urlimg/urlimg.c demo/products/prmodel.c

Position In The Stack

The target declaration is nap_library(inet "encode" ...). Startup follows the usual reference-counted pattern: the first inet_start() call starts encode and the platform HTTP backend; the last inet_finish() call shuts the backend down and then finishes encode.

Like encode, inet is not part of nappgui.h. Code that uses networking includes <inet/inet.h> and <inet/httpreq.h> explicitly.

Public API Shape

The center of the API is Http. You create it with http_create() or http_secure(), add request headers, perform a GET or POST, and then inspect the parsed response line, response headers, and response body.

If the caller passes UINT16_MAX as the port, the constructors normalize that to 80 for plain HTTP and 443 for HTTPS. Error reporting is coarse by design and flows through the ierror_t enum.

Responses Are Parsed Lazily

After http_get() or http_post(), the raw response stays in the backend object until one of the response accessors is called. At that point httpreq.c reads the header stream, parses status lines and header fields, and caches the final values in the portable Http object.

There is one subtle point here: if the raw headers contain multiple response blocks because of redirects, the parser keeps the last status line and clears earlier headers. Header lookup is case-insensitive, because the cached header array is searched with str_equ_nocase(...).

Convenience Helpers Use The Encode URL Parser

http_dget() and http_exists() are convenience wrappers around the lower-level Http object. Both call url_parse() from the encode library, choose HTTP versus HTTPS from the parsed scheme, rebuild the resource path with url_resource(), and then issue a request.

http_dget(): performs a GET, returns the response body as an in-memory Stream, and optionally reports the HTTP status code.
http_exists(): performs a GET with auto-redirect disabled and only returns true for status codes in the 200..299 range.

There is no HEAD helper, no incremental callback API, and no broader REST surface. This library is intentionally much smaller than a general-purpose HTTP SDK.

Platform Backends

Platform	Backend	Notable Behavior
Windows	WinINet	Uses `InternetOpen`, `InternetConnect`, and `HttpOpenRequest`; request headers are accumulated in a UTF-16 stream before sending.
macOS	`NSURLSession`	Uses session delegates, maps Cocoa networking errors onto `ierror_t`, and stores response headers/body in NAppGUI streams.
Linux	libcurl	Uses one curl handle per `OSHttp`, writes headers and body through callbacks into memory streams, and initializes libcurl globally in `oshttp_init()`.

Build And Consumption Notes

The CMake helper nap_link_inet_depends(...) links encode plus the platform dependency: wininet on Windows and libcurl on Linux. There is no extra link helper on macOS because the implementation is built against the system frameworks already available to the platform build.

One packaging detail is easy to miss: the package-side helper nap_link_inet(...) is written to link nappgui::inet, but the convenience NAPPGUI_LIBRARIES list in prj/nappgui-config.cmake stops at encode. So consumers that rely only on that convenience variable do not pick up inet automatically.

What The Demos Use It For

demo/urlimg uses http_dget() to download images into a Stream and then feeds that stream into image_read(...). demo/products uses the lower-level Http object directly so it can inspect status and body separately before passing the response into the JSON layer.

Those demos match the library's real role in the stack: it is a simple transport layer meant to hand complete response payloads to other NAppGUI subsystems rather than a full featured networking framework. The dedicated Inet API Examples page extracts the common request patterns directly from those demos.