Skip to content

Conversation

@31415-n
Copy link

@31415-n 31415-n commented Jun 7, 2025

Previously, HTTP error responses (4xx, 5xx) would throw exceptions instead of allowing access to response information. This made it impossible to handle API errors gracefully in Lua scripts.

Changes:

  • Capture response code/message/headers before attempting to read stream
  • Use getErrorStream() for HTTP error responses instead of getInputStream()
  • Provide empty stream fallback when getErrorStream() returns null
  • Preserve existing behavior for successful responses (2xx)

This allows scripts to check response codes and read error response bodies using the existing response() and read() methods.

Fixes #3663

Previously, HTTP error responses (4xx, 5xx) would throw exceptions
instead of allowing access to response information. This made it
impossible to handle API errors gracefully in Lua scripts.

Changes:
- Capture response code/message/headers before attempting to read stream
- Use getErrorStream() for HTTP error responses instead of getInputStream()
- Provide empty stream fallback when getErrorStream() returns null
- Preserve existing behavior for successful responses (2xx)

This allows scripts to check response codes and read error response
bodies using the existing response() and read() methods.

Fixes MightyPirates#3663
@asiekierka
Copy link
Contributor

asiekierka commented Jun 12, 2025

// TODO: This should allow accessing getErrorStream() for reading unsuccessful HTTP responses' output,
// but this would be a breaking change for existing OC code.

The problem with the solution is still that a lot of existing OC programs do not handle error responses which are not exceptions; since the mod is on life support, breaking existing OC programs is unacceptable.

@31415-n
Copy link
Author

31415-n commented Jun 15, 2025

Okay, I’ve added a new parameter to the request method. This change maintains full backward compatibility with existing code.

You can run this Lua script with automated tests to verify the behavior: https://pastebin.com/v6jpmDS7

The test confirms that backward compatibility is preserved: when allowErrorBody is set to false (or not provided at all in the request() method), only HTTP status codes 200, 201, and 202 are treated as successful responses. All other codes (such as 400, 404, 500, etc.) result in an exception being thrown, which matches the original behavior.

However, when allowErrorBody is set to true, the method follows the new logic: even for HTTP error responses (4xx, 5xx), the response body is returned instead of throwing an exception. This allows developers to handle error responses programmatically without interrupting execution.

In summary, the addition of the allowErrorBody parameter enhances the flexibility of the request method while preserving full backward compatibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Internet API Throws Exception for HTTP Error Response (again)

2 participants