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

Suggestion for HTTP 1.0

From: <Dove@eworld.com>
Date: Thu, 23 Mar 95 08:30:44 PST
Message-Id: <9503230830.tn68105@eworld.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Dear Team,
I represent a firm producing HTTP clients and servers for use in vertical
mobile computing environments, using PDA-style devices.  In the last year, we
have produced a HTTP 0.9 compliant browser, and are currently collaborating
with other firms to produce a HTTP 1.0 compliant browser and proxy server for
wired or wireless access to devices which may or may not have an underlying
TCP/IP stack.  To this end, we have reviewd the draft IETF HTTP spec (0.1,
dated 19 December 1994, expiring June 19, 1995) quite thoroughly, and it has
been very useful in both the development of our implementation and in
developing proxy servers for this and other applications.

In our work, we have seen a fairly strong need to reduce the amount of
document
data transferred between proxy and mobile client - traditionally, this link
is
achieved via a slow-bandwidth or high-byte-cost connection (or more often,
both) such as the ARDIS network or a 2400bd modem connection. 

As we approach incorporating HTTP 1.0 support, we have debated adding a
subdocument query extension to HTTP, to support the following scenario:

1. The mobile client requests a document from the proxy, indicating it only
 wants a single "page" (of client-specified length).
2. The proxy fetches the full document (or perhaps only the first page,
 depending on the version of its source)
3. The proxy returns the desired "page" to the client.

This page is an arbitrary range of bytes, which requires that the client have
some mechanism of dealing with fragmented data (split HTML tokens, for
example,
or reuniting pieces of a split graphic as required).  By allowing this
"paging"
to be performed by the proxy, which presumably has an inexpensive
high-bandwidth connection, we can decrease transfer time and transfer cost. 
Our user studies have indicated that in a large number of situations, only a
small segment of a document (usually, although not always, the beginning) is
used by a user before pursuing another.  Rather than using a start/stop
scheme,
we thought that this paging mechanism would be more robust.

Based on our experience in mobile data transfer, we think an extension to the
Request 
Header of HTTP 1.0 requests to permit the request of only a certain byte
range
may be of use to more than just us and our customers; as wireless access to
the
network grows, proxy servers used by wireless providers could offer this
mode to lower transfer time and save customer costs, for example.  Thus, we
felt it would be best to call your attention to our efforts in the hopes that
a
unified standard for this mechanism could be made.

We would thus respectfully submit an additional keyword to the Object header
to
denote the range of octets for a particular document being requested.  This
keyword 
would be known as Octet-Range, and perform as follows.

BNF Description of Octet-Range in the Object Header:
Octet-Range = "Octet-Range" ":" start "-" end
 start  =  1 * DIGIT
 end  = 1 * DIGIT
 
Requests including the Octet-Range Object Header would generate responses
containing only those octets in the Object Body offset by the
start value (counting from zero) and through the end, or the end of the
Object
Body, whichever resulted in the smallest Object Body.  It is an error to
return
Octets before the indicated start offset, or after the indicated end offset. 

A response incorporating the Octet-Range would return the Octet-Range of the
request, and the associated octets of the Object Body as the Object-Body.  In
the event that the end offset was greater than the total number of octets,
the
Octet-Range Header still has its original value, but the Content-Length
Object
Header shall indicate the number of octets actually returned.  (The client
may
be able to then deduce the true total length of the document as its start
plus
the returned number of octets without the need for a HEAD request).

Your consideration of this matter is appreciated.  Please feel free to
contact
us with any comments, questions, or feedback you may have.



 Best Regards,
 Ray Rischpater
 Software Craftsman
 AllPen Software, Inc.
 (408) 399-8800 voice
 (408) 399-4395 fax
 dove@allpen.com dove@eWorld.com
Received on Thursday, 23 March 1995 08:41:37 EST

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