The V2 client starts each request, checks its progress, then closes it before handling the HTTP result. It can still report an error if the response body is valid. It can also receive a successful HTTP status but fail to parse the menu, document or PPM that follows. [1]
Request states
In the examined V2 handler, state 1 starts the request and state 2 polls it. State 3 records HTTP success; state 4 records failure. One transport-status value means the request is still pending, two lead to result handling, and the others lead to error reporting and closure. These state numbers describe the client's implementation, not HTTP itself. [1]
Dialogues and forward navigation
A server can return UTF-16LE text for a client modal, with a body length capped by the client's dialogue handler before display. Some response headers can request forward navigation, but the observed client bounds their length. When testing a response, check that the DSi opens the intended screen. Checking that the header is present is not enough. [1][2]
Numeric errors
The original US HTTP error worker maps a positive HTTP status into a client-facing code by adding 340000; transport errors use a different offset. A displayed number therefore needs to be decoded in the context of the worker that produced it. For example, an HTTP 404 can be displayed with a code beginning 340 instead of “404”. [1]
Debugging sequence
- Record exact client build, request URL and response status.
- Record content length, content type and body bytes.
- Check whether the request handler reached the code that processes the result.
- Check the parser or file-commit stage separately.
- Match any displayed error to the responsible client worker. [1]