W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Other transfer codings

From: Peter J Churchyard <pjc@trusted.com>
Date: Mon, 19 Feb 1996 13:56:50 -0500 (EST)
Message-Id: <9602191856.AA18296@hilo.trusted.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Hi I would like to see other transfer codings in the 1.1 spec. The following
is a rough of the sort of thing that could be used.

Pete.
------------------------------------------------------------------------
Existing protocols on the net have a number of ways to
provide end of content markers in a data stream. This document proposes
the dot stuffing mechanism that is used in protocols such as RFC1725, 
RFC 821 and others. It also proposes another Record coding mechanism as
used in the SSL draft.

Transfer-coding: dot-stuffed

This coding is most applicable to text orientated streams. The end of content
marker is the character sequence
	<CR><LF>.<CR><LF>
When the stream has data that starts a line with a "." then a "." is pre-pended.
On reception, when a line starts with a "." then the leading "." is discarded.
Given the varying nature of end of line in http bodies, the entire sequence
of <CR><LF>.<CR><LF> is taken as the marker. This allows for text bodies that
don't end in an End of Line.

Examples.
	An empty body (length 0 bytes) is coded as
	<CR><LF>.<CR><LF>

	The text 
		Now is the time<lf>
		. etc etc<lf>

	is coded as
		Now is the time<lf>
		.. etc etc<lf>
		<cr><lf>.<cr><lf>

	and
		Now is the time<cr><lf>
		. etc etc<cr><lf>

	as
		Now is the time<cr><lf>
		.. etc etc<cr><lf>
		<cr><lf>.<cr><lf>



Transfer-coding: record

The record coding uses the same format as used in the SSL draft standard. This
considers the content as a set of records. Each record has a two or three byte
header that says how many data octets are in the record body. The three byte
version allows some padding to be specified. The EndOfContent marker is a 
three byte sequence that indicates 0 bytes of data and 0 bytes of padding. So
two byte headers specifying 0 bytes of data can be used without implying EOC.

The record header is a two byte header if the most significant bit of the
first byte is 0. The two byte value is in "network order". This allows a
record with a two byte header to be 32767 bytes (octets) long. Note there is
no implied boundary between records. The actual content is to be considered
as a continuous stream.

A three byte header has the most significant bit of the first byte set to 1.
the next most significant bit is set to 0. The length of the data part is the
least significant 6 bits of the first byte and the 8 bits of the second byte.
The third byte is the number of padding bytes. The actual length of the data
part is the length of the record less the length of the padding. It is an
error to specify a padding length that is longer than the data length value.

An End Of Content is thus encoded as the three octets (in hex) 80 00 00.


transfer-coding = "chunked"|"dot-stuffed"|"record"|token

Stuffed-body = *stuffed-line EndOfContent footer CRLF
EndOfContent = CRLF"."CRLF

Record-body = *record EndOfRecord footer CRLF
record = record-header n*n record-data
record-header= two-byte-header|three-byte-header
EndOfRecord = <three octets with the values (in hex) 80 00 00>
Received on Monday, 19 February 1996 11:02:02 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:45 EDT