RE: Padding size in chunked encoding

However, even if you are using "direct" buffering then I can't see why you
can't count backwards from the start of the data and then let the start of
the size part vary (no param in this example):

                       x x x x x x | x x x x x x ...
                                 |   |
                     <- size start   data start ->

or use vwrite for writing multiple buffers at once.

[Phillip M. Hallam-Baker]  
(Why does outlook insist on sticking my name in front of annotations??)


Henrik is also right, provided you only send one packet at a time. If you have
a need to assemble two chunks simultaneously this option may not be
available.

Consider the following corner case. You have a stream of data that continuously
adds data into a buffer. From time to time the stream controller synchronizes
with the transport dispatcher process to inform it that a chunk is complete. 
Most times the dispatcher sends one TCP/IP packet per chunk however from
time to time the TCP/IP flow control backs up causing the transport dispatcher 
to discover that there are *two* chunks to be sent in a single packet.

I don't expect this type of thing to occur in a standard Web server application
but I could imagine cases where a dedicated "proxy bridge" might want to
make sure the last epsilon was squeezed out...

The type of ultra high bandwidth services where there is a real issue could
be better handled by a semantically neutral binary format for HTTP. IE the
RFC-822 headers would be replaced by a tightly packed binary format which
would handle chunking natively. I don't think such a format needs to introduce
the changes to the HTTP semantics that Simon proposed in HTTP-NG to
be usefull. Alternatively the MUX proposal may be the answer.


Again, we have had this discussion at the time, the spec has gone to RFC
and its too late to change it now. I got criticized enough for bringing it up
six months before the spec went out (ie at the point where everyone was
hoping to send it in in about a fortnight :-). I fail to see the point of 
discussing it at length now.


	Phill

Received on Friday, 21 February 1997 10:55:04 UTC