> GET /path/ http/1.0
> Relative-URI: fred.html
> Relative-URL: jim.html
>
> This allows multiple requests in one GET. Note that only a single response
> is returned, a multipart MIME.
This is the most sensible proposal for multi-request
transactions I've seen. With this scheme, it would
take at most two TCP connections to fetch an HTML document
with all its associated inline graphics, annotations, &c.
Two connections seems reasonable.
You don't address protocol negotiation, though, which
I think will be necessary: existing servers would interpret
the above multi-object request as a single request for '/path/', and
new clients wouldn't have any way to tell that what they got back
isn't what they asked for. (Checking for 'Content-Type: multipart/xxx'
in the reply won't work, since that's a legitimate HTTP/1.0 reply.)
Why not call the method 'MGET' and the protocol 'HTTP/1.1'?
One other question: how does the client tell which body
part in the response corresponds to which request?
>One point:
> BURN PRAGMAS !
> PRAGMAS ? - JUST SAY NO.
>
>Pragma keep alive is NOT acceptable. You are modifying the protocol completely
>and not even using a tag. METHOD /url/ HTTP/2.0 is the only acceptable solution
I concur wholeheartedly.
"Session-oriented" HTTP where the connection stays open
may be useful in the future, but a single-transaction,
multiple-object GET request is easier to do and solves
a lot of problems *today*.
--Joe English