# IMVU's hosts

The hosts the client (554.8) reached through the proxy in a session of logging in, the home screen, the shop,
the chat room list and joining a room, and how the proxy treats them.

## Upgraded to HTTPS

The client asks for these over plain HTTP. Each served the same bytes over HTTPS for the paths the client used
(checked 2026-10-29: the same responses over both, and the client's session over HTTPS worked):

| Host | What the client gets there |
| --- | --- |
| `client-dynamic.imvu.com` | XML-RPC API (`/api/xmlrpc/client.php`), avatar cards, actions, CSS for the UI |
| `chat.imvu.com` | XML-RPC chat API (`/api/xmlrpc/chat.php`) |
| `chatnow.imvu.com` | the same, for Chat Now |
| `www.imvu.com` | web pages the UI embeds |
| `userimages-akm.imvu.com`, `userimages01-akm.imvu.com` ... `05` | avatar pictures, room and product images |
| `webasset-akm.imvu.com` | resized images |
| `static-akm.imvu.com`, `static.imvu.com`, `userimages.imvu.com` | static files |

If a request over HTTPS fails before reaching the server, the proxy retries it over HTTP.

## Left alone

- `api.imvu.com`, `secure.imvu.com`: the client already uses HTTPS.
- `product.virtual.imvu.com`, `program.virtual.imvu.com`: no HTTPS (the TLS connection fails).
- `imq.imvu.com:443`: IMQ, reached with CONNECT (TLS from the proxy).

## Refused

`bugs.imvu.com`, and on any host `/api/drv.php`, `/api/increment_counter.php`, `/api/record_gauge.php`,
`/catalog/web_submit_logs.php`, `/catalog/imvu_monitor_submit.php`, and `api.imvu.com/events`: crash reports,
logs and metrics, as T5DE's `reporting-blocklist` patch refuses them in the client.

## Observed

- `POST https://api.imvu.com/room/room-<owner>-<n>` answers 403 when joining someone else's room, with or
  without the proxy (the client logs `HTTP Error 403` either way).