I don't think their proxy server would use Opera Mini as the user-agent. What I seem to remember, was that they run this proxy which did the fetching for you, did some ridiculous compression or similar, and then sent you the compressed reply.
If I remember this correctly, I'd expect the user-agent to be something like "Opera Proxy" or "Opera Compressor", not the user agent of the browser itself. But again, I might remember this all incorrectly, was a long time ago and I was just a kid.
> I don't think their proxy server would use Opera Mini as the user-agent.
It does, I just checked:
> Opera/9.80 (Android; Opera Mini/87.0.2254/191.361; U; en) Presto/2.12.423 Version/12.16
> What I seem to remember, was that they run this proxy which did the fetching for you, did some ridiculous compression or similar, and then sent you the compressed reply.
That's Opera Turbo, a feature of Opera Mobile (which is a full browser, HTML, JavaScript and all), which indeed compressed images and other media in a lossy way (and text losslessly, if it wasn't already at the HTTP level, I assume).
Opera Mini actually renders HTML (and executes JavaScript for a couple of seconds) server-side and then sends a binary version of that pre-render to the phone. I imagine it to be closer to SVG or PDF than to HTML and CSS.
I know the user causing those log entries personally. They use Opera Mini on an ancient SymbianOS phone.
Yes, it works like you describe. They use a compressed protocol between the client and the proxy. The DOM might not even be based on HTML, not sure about that.
> The DOM might not even be based on HTML, not sure about that.
IIRC the page is loaded server side, javascript executed, and then essentially a screenshot taken, and some markup to show where the links and buttons are.
That is still running. The SymbianOS version of the Opera Mini browser still works.
From my Web server log: