Re: Protocol Benchmarking (HTTP protocol)

Dave_Raggett <dsr@hplb.hpl.hp.com>
Errors-To: secret@www0.cern.ch
Date: Fri, 4 Feb 1994 19:28:13 --100
Message-id: <9402041822.AA17370@manuel.hpl.hp.com>
Errors-To: secret@www0.cern.ch
Reply-To: www-talk@www0.cern.ch
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Protocol Benchmarking (HTTP protocol)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 3092

Chris,

>> Before we set about support for multiple GETs, browsers should try taking
>> advantage of "Accept: multipart/related" to request a document and its
>> inlined images with a single GET. The HTTP standard specifies how to do
>> this now!

> Where?  The version of the standard I'm using is the Internet Draft.  Where
> can I get the version with the multipart/related spec?  I'd like to
> implement it in the Windows NT server.

Have a look at

  http://info.cern.ch/hypertext/WWW/Protocols/HTTP/Object_Headers.html

The idea is as follows:

If the client can wants to receive the HTML document and the inlined images
as a single MIME message, it includes multipart/related in the Accept: field
as part of the header. You will probably want other Accept: fields to cover
the content types of constituent body parts. Refer to the above for details.

When the server receives such a request, it builds the requested HTML
document into a MIME multipart/related message. Note that the last paragraph
of section 7.2.1 of RFC 1341 states that the notion of stuctured, related
body parts is missing from the core spec, and that standard MIME mail handlers
will treat Content-type: multipart/related as equivalent to multipart/mixed
and will thus still be able to show the user the separate parts.

The MIME message will look like:

    MIME-Version: 1.0
    Content-type: multipart/related; boundary="simple boundary"

    --simple boundary
    Content-type: text/html
    URI: <this documents URI>

    <title>the html document</title>
    etc.
    --simple boundary
    Content-type: image/gif
    URI: <uri for 1st inlined image>

    ...The gif image data ...
    --simple boundary
    Content-type: image/gif
    URI: <uri for 2nd inlined image>

    ...The gif image data ...
    --simple boundary--
    
Notice the URI header is used to identify the URI for each part.
This makes it easy to stick each part into your local cache and
there after use the URI to fetch the images from the cache with
no extra hassle. I have used MIME's boundary mechanism above, and
the final deliminator has a terminating "--" while preceding ones
don't. You could also include the Content-length: field to specify
the length of each part and of the message overall, e.g.

    MIME-Version: 1.0
    Content-type: multipart/related
    Content-length: <combined lengths of parts and their headers>

    Content-type: text/html
    Content-length: <length of this body part>
    URI: <this documents URI>

    <title>the html document</title>
    etc.
    Content-type: image/gif
    Content-length: <length of this body part>
    URI: <uri for 1st inlined image>

    ...The gif image data ...
    Content-type: image/gif
    Content-length: <length of this body part>
    URI: <uri for 2nd inlined image>

    ...The gif image data ...

Here, I have omitted the boundary deliminators which is perhaps a
mistake as it would make it impossible for standard mailers to
find the body parts. On the other hand, such mailers wouldn't
normally be fed the output of an HTTP server ...


Regards,

Dave Raggett