For the asynchronous mode, you're are missing a parameter for the protocol itself (well, synchronous mode also suffer this problem), I don't think enforcing http 1.1 is a good idea (that could change to a greater version anyway), we should be able to specify 1.0.
Not sure I agree here. Enforcing 1.1 is a super great idea, because it's the current standard, and almost all user agents use it. It's a widely accepted default. I'd be surprised if you can find a single server that
only supports 1.0 requests. I don't see any reason to ever need to send a 1.0 request in 2015. HTTP/2 is already being built out (your browser probably already supports it), HTTP/1.0 today would be like using HTML3 to build web pages. Forcing 1.0 would break connection keep-alives and plenty of other stuff. In general, there's no need for the client to control this. Remember, the whole point of this is that mIRC is abstracting the protocol. The user typically shouldn't care what protocol version is being used. The idea is that mIRC could eventually upgrade its internals to use HTTP/2 without users even knowing or caring, when it becomes the standard, assuming the protocol fundamentals remain compatible (
which they likely will).
Of course, you could always add a switch for this later if there was a good reason for it, but I've never needed to drop down to 1.0 for any HTTP clients I've used... ever.
I like the idea for a timeout in synchronous mode, I'll add that.
I don't understand this, did you mean an error if /httpsend is used without /httpstart?
This is poorly written-- I mean /httpstart should fail if there is a pending transaction, i.e., you cannot call /httpstart twice in a row on the same session.
For the session, I rather think that by default, it should be disabled, that we should be able to enable it with a switch in /httpstart, sounds better imo, but can't really tell why.
Are you suggesting that session handles would be optional and by default it would just use some "main session"? I suppose this could work for sending requests, but scripting the response events would be pretty much impossible without some kind of handle ID to associate your events with. You wouldn't want script Bar triggering for a request sent by script Foo because they were (ab)using the main session. With the -o switch, handles are pretty lightweight and easy enough to use.
