7.6 Transfer Codings idea...?

It would be very useful to extend the chunked Transfer Coding to allow the
processing of a second request in a pipe-lined connection between or before
sending the chunks for the first request.  An example would be if the first
request sent would require some time to respond to, but the second request
could be fulfilled immediately, or if the response to the first request
used a Netscapism like server push.

Such a system would be simple to impliment in the protocol, by adding an
identification tag to each chunked-block, and allowing the server to pause
transfer of one chunked-block and begin transfer of another.  Consider the
following changes...

7.6 Transfer Codings
Transfer coding values are used to indicate an encoding transformation
that has been, can be, or may need to be applied to an Entity-Body in
order to ensure safe transport through the network. This differs from a
content coding in that the transfer coding is a property of the message,
not of the original resource entity.

-       transfer-coding         = "chunked" | transfer-extension
+       transfer-coding         = "chunked" [ 1*SP id ] | transfer-extension
+
+       id                      = "id" "=" id-param
+       id-param                = token

       transfer-extension      = token

All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer
coding values in the Transfer-Encoding header field (section 18.43).

Transfer codings are analogous to the Content-Transfer-Encoding values
of MIME , which were designed to enable safe transport of binary data
over a 7-bit transport service. However, "safe transport" has a
different focus for an 8bit-clean transfer protocol. In HTTP, the only
unsafe characteristic of message bodies is the difficulty in determining
the exact body length (section 11.2.2), or the desire to encrypt data
over a shared transport.

All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer coding , and MUST ignore transfer coding extensions
they do not understand. A server which receives a an entity-body with a
transfer-coding it does not understand SHOULD return 501(Unimplemented),
and close the connection. A server MUST NOT send transfer-codings to a
client that were not defined in the version of HTTP used in the client's
request. Clients sending entity-bodies with transfer-codings SHOULD must
be prepared for the connection to be closed if the server doesn't
understand the transfer-coding.  The chunked encoding modifies the body
of a message in order to transfer it as a series of chunks, each with
its own size indicator, followed by an optional footer containing
entity-header fields. This allows dynamically-produced content to be
transferred along with the information necessary for the recipient to
verify that it has received the full message.

+ In the case where the client sends pipe-lined requests, the server MAY
+ send an id value in the transfer-coding value to indentify which chunks
+ correspond to which response.  If the server wishes to respond to
+ pipe-lined requests in any order other than first in first out, it MUST
+ include the id value, and the id value MUST be unique and unused by any
+ other entities in the same connection.

-       Chunked-Body   = *chunk
-                        "0" CRLF
-                        footer
-                        CRLF

+       Chunked-Body   = [id CRLF]
+                        *chunk
+                        ("0" | "!") CRLF
+                        footer
+                        CRLF

       chunk          = chunk-size [ chunk-ext ] CRLF
                        chunk-data CRLF

       chunk-size     = hex-no-zero *HEX
       chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
       chunk-ext-name = token
       chunk-ext-val  = token | quoted-string
       chunk-data     = chunk-size(OCTET)
+
+      id             = "id" "=" id-param
+      id-param       = token

       footer         = *<<Content-MD5 and future headers that specify
                         they are allowed in footer>>

       hex-no-zero    = <HEX excluding "0">

Note that the chunks are ended by a zero-sized chunk, followed by the
footer and terminated by an empty line. An example process for decoding
a Chunked-Body is presented in appendix 23.3.6.

+ If an id value is given with the transfer-coding value, the server MAY
+ include an id value with the Chunked-Body.  If the chunked-body is being
+ sent to resume a paused transfer, the id MUST be included.  The id-param
+ for the chunked-body MUST BE the same as the id-param listed in its
+ corresponding headers.  If a chunked-body is received by the client with
+ an id-param that is not identical to an id-param received in a reponse
+ header before it, it SHOULD ignore it.
+
+ If the chunked-body is delimited by "0", the response to the client is
+ ended.  If the chunked-body is delimited by "!", the response to the
+ client is paused.  The server MAY resume sending a paused response later.
+ If no id is given in its corresponding Transfer-Encoding header, or if the
+ connection is closed before the transfer is resumed, the client SHOULD
+ treat "!" as identical to "0".

17.2.2 Pipe-lining
Clients and servers which support persistent connections MAY "pipe-line"
their requests and responses. When pipe-lining, a client will send
multiple requests without waiting for the responses. The server MUST
then send all of the responses in the same order that the requests were
- made.
+ made, althogh, if it sends the entity bodies in chunks and includes an
+ id in the Transfer-Encoding headers, it MAY pause the response as
+ described in section 7.6, and MAY resume the response later, by sending
+ an appropriate chunked-body, at any time that it is not in the process
+ of responding to an unpaused request on the same connection.

I think that this would allow the server much more flexability, and would
result in more effecient use of the connection, as idle time could be spent
fulfilling another request, rather than sitting and waiting for a time
intensive task to be finished.

Richard Connamacher

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2

mQCPAzEtexUAAAEEALPfu202DEwxLQ96BwKL5liDPzdCVox/iSbc201h5oTzLGmT
v1PU+TmeS/lEtTvVe5WVZ3iDjjKDcoWwc1MRmbCMMVosywXEiXoLqWBTj+hlcKXA
//TpyK4RRBZodr6eFesy2wSphpXTtJnIduKMDP0XuVgcrOILMUa1Zcdw+pa1ABEB
AAG0LVJpY2hhcmQgQ29ubmFtYWNoZXIgPHBoYW50b21AYmF5bW9vLnNmc3UuZWR1
Pg==
=iME4
-----END PGP PUBLIC KEY BLOCK-----

Received on Saturday, 25 May 1996 12:04:02 UTC