wip http feature rewrite fuckery

[ZeWaka]

Important

WIP DON'T REVIEW THIS WIP

WIP DON'T REVIEW THIS WIP

This will be a breaking change, resulting in a major version

Impetus behind the change

Currently, error codes like 404 cause it to just stringify the error and return, instead of returning a more complex object like the current non-error response.
This causes the status code, headers, body and such to not be set for an erroring code like 404 (according to the current, default behavior).

I could just change these to no longer be errors (like I've done here, still a breaking change), but while we're here, we can give consumers a much better interface for dealing with errors.

Change

So, I'm changing the http lib Response to be:

struct Response<'a> {
    status_code: u16,
    headers: HashMap<String, String>,
    body: Option<&'a str>,
+   error: Option<&'a str>,
}

to then mirror into a improved shared error datum

/datum/http_response
	var/status_code // The HTTP Status code - e.g., `"404"`
	var/body // The response body - e.g., `{ "message": "No query results for xyz." }`
	var/list/headers // A list of headers - e.g., list("Content-Type" = "application/json").
	var/errored = FALSE // If the request errored, this will be TRUE.
	/// If there was a 4xx/5xx error or the request failed to be sent, this will be the error message - e.g., `"HTTP error: 404"`
	/// If it's the former, `status_code` will be set.
	var/error

As a part of the above, rust-g will also now distribute the standard /datum/http_response and /datum/http_request datums that all of SS13 uses. This will let people lean on a more unified standard, that's distributed with the actual library implementing this on the backend.

Internally, a lot of the was refactored due to ureq being updated to 3.0, necessitating a lot of pattern changes.

[AffectedArc07]

So

what does the refactor do apart from adding /datum/http_request in.

[ZeWaka]

So

what does the refactor do apart from adding /datum/http_request in.

did you not read my discord post?
<-- image snip -->

Edit: this is also a draft PR with WIP in the title. I'll clearly document it later lol

[AffectedArc07]

No I have better things to be doing, could have easily clarified without the snark.

So
what does the refactor do apart from adding /datum/http_request in.

did you not read my discord post?

[Copilot]

Pull Request Overview

This PR rewrites parts of the HTTP handling and related modules, updating APIs and error reporting while replacing once_cell with LazyLock for several shared resources. Key changes include updating the HTTP client request construction and response parsing (src/http.rs), enforcing response size limits in the unzip feature (src/unzip.rs), and updating dependency initializations across sql and iconforge modules.

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/unzip.rs	Updated request type and added content-length checking and limit logic
src/sql.rs	Replaced once_cell::Lazy with std::sync::LazyLock
src/iconforge.rs	Updated caching initializations to use LazyLock
src/http.rs	Refactored request construction/response parsing; added error field
src/error.rs	Updated error variants to support new HTTP and parsing errors
dmsrc/http.dm	Adjusted DM interface to align with updated HTTP response format
build.rs	Minor cleanup when concatenating feature DM files
Cargo.toml	Updated dependency versions and removed once_cell for HTTP, sql, iconforge

[Copilot]

[nitpick] Using unwrap_or to default to GET on method parse failures might hide invalid HTTP methods. Consider explicitly handling invalid method strings with proper error feedback instead of defaulting silently.

[ZeWaka]

I'd need to check for incompatibilities in existing uses to see if it's a widespread thing. I don't think the DM API allows this, so could be good to error.