For each request, the original V2 code chooses a method, builds the URL, attaches any headers and body, and sets the response-buffer limit. It then submits the request to the network code and polls for completion. Knowing a route alone does not tell you these settings, and tracing request construction does not confirm that it was delivered. [1]
Action classes
- Navigation: fetch a UGO or document and dispatch according to the returned resource type.
- Metadata action: send a POST for a star, favourite or related control, using metadata from the current page.
- Posting: submit a PPM as the body of a Flipnote or drawn-comment request.
- Download: fetch a remote PPM, commit it and pass it to the player or local file path. [1][2]
Body and header distinction
The studied V2 POST worker binds a raw body pointer and length rather than transforming it to JSON or multipart form data. Nonempty bodies outside one special route receive application/octet-stream; it also installs a keep-alive header. A metadata action with an empty body is therefore different from a posted PPM even though both use POST. [1]
Star example
One original archive action searches a temporary URL for the first case-sensitive .ppm, rewrites it with a configured suffix, and sends a count in X-Hatena-Star-Count. If the string lacks .ppm, that worker returns before submitting. This is one client action, not a universal rule for all star UI. [1]
Checking whether an action succeeded
The original code proves what it attempted to send and how it handled the result. It does not by itself prove that a historical server accepted the action or changed a database. Verify successful behaviour with a response capture and the resulting screen. [1][2]