The client sends it every HTTP request and its IMQ connection; it makes them with current TLS and certificates, upgrades IMVU's plain-HTTP hosts to HTTPS, and refuses IMVU's reporting endpoints. CI tests it and publishes t5de-proxy.exe as nightlies and tagged releases. Co-Authored-By: Claude Opus 5.5 <[email protected]>
1.8 KiB
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 logsHTTP Error 403either way).