Well, I'm not saying we should force 1.0, but some servers will default to gzip encoding in the response on 1.1, while they wouldn't on 1.0, which makes thing complicated in mIRC scripting, at least I recall some tricky situation like this, I agree otherwise.
Ah, well this is another reason HTTP abstractions shine-- a Transfer-Encoding of gzip should be handled transparently by the user-agent (mIRC), and should be invisible to the user. In other words, scripts should be able to parse gzip encoded responses without even needing to know that they are gzipped, because it should be unpacked by mIRC prior to getting to the user. This is what almost all HTTP abstraction libraries do in other languages, and likely what WinHTTP does (or can do) if that library were to be used to implement this. We would actually WANT mIRC to use gzip compression whenever possible, since it would improve network transfer speeds, so I would actually imagine that mIRC would have gzip on unless otherwise specified. I actually forgot to add this to benefits list.
Incidentally you can disable gzip transfer on most servers, even with HTTP/1.1, by providing an Accept-Encoding header of 'identity' or empty string. Any server that handles HTTP/1.1 (read: virtually every server) will understand this. But again, a client shouldn't be doing this unless there is a good reason to force the user-agent to disable compression across the wire, since it doesn't represent the data that the user deals with. But yea, if you wanted to forcibly disable gzip, this is how you should be doing it,
not by dropping down to HTTP/1.0.
And to answer the session/handle question: yes, a handle refers to a handle to a session. Handle == session, pretty much. I might have alternated the terms a few times, and admittedly, I considered renaming "handle" to "session" midway through the proposal. It could be, if that simplifies things.
