I wrote a very simple addition to HTTP/1.1 in which I plan to draft as a RFC soon, which allows multiplexing, prevents HOL blocking, and allows server pushing in HTTP/1.1. HPack could also be incorporated, via negotiation. The idea? A request begins by adding a header: X-Req-ID, set to a connection-unique value. The server responded with an exact copy of this ID, and a X-Req-Target header which specifies the location of the response(for server pushing mostly). The server sets the X-Req-ID = push/based-id for pushed responses. In doing so, we do away with the standard in-order processing & one-response-per-request model. Furthermore, A server may send many 206 Partial Contents for Transfer-Encoding: chunked responses, and must not send any in the initial response denoting a transfer. The request headers for pushed responses are equal to the response they are coming from, with any caching data removed. It is planned to allow the client to push more caching info for pushed information.
Example: GET / HTTP/1.1 Host: 127.0.0.1 If-None-Modifed: "random etag" X-Req-ID: 1 HTTP/1.1 200 OK X-Req-ID: 1 X-Req-Target: / Content-Length: 1024 ...1024 bytes of data... HTTP/1.1 200 OK X-Req-ID: push/1 X-Req-Target: /logo.png Content-Length: 65535 Content-Type: image/png ...65kb... I have a slightly less refined implementation which uses a static -PUSH- X-Req-ID available @ www.avuna.org or https://github.com/JavaProphet/Avuna-HTTPD for source code. The to-do list comprises at the moment of a efficient system for specific more complex push caching, to avoid re-pushing already known data. One possible system is to allow multiple ETag/Last-Modified or other cache-related header fields in the initial request. Ex. If-None-Modified: /="blah" /logo.png="blah2" Another is to use a 'master-etag/last-modified' that assumes the pushed content is there. (But what if some updates?) A HPack negotiation is planned, perhaps after the server acknowledges that the connection is extended, it will encode with HPack instead of standard. Also X-HPACK: <hpack binary> perhaps to allow legacy processing to be more efficient? I would like to see some form of this support by Firefox to allow further testing and development. Not only is it not as complicated as HTTP/2, but it has theoretically much faster potential without all the nasty protocol negotiation and upgrading, as well as the virtualized stream overhead, which seems to be unnecessary. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
