Re: Protocol Benchmarking (with Accept examples - long)

• Mail folder: WWW Talk Jan 94-present
• Next message: Stephen P.Cohen: "DTD for HTML+"
• Previous message: Vinay Kumar: "Re: Protocol Benchmarking (HTTP protocol)"
• Reply: Alexsander Totic: "Re: Protocol Benchmarking (with Accept examples - long)"

Message-id: <m0pRqP4-00041AC@ibeam.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 2 Feb 1994 14:52:54 -0800
To: koblas@netcom.com (David Koblas), mcrae@ora.com (Christopher J. McRae)
From: altis@ibeam.jf.intel.com (Kevin Altis)
Subject: Re: Protocol Benchmarking (with Accept examples - long)
Cc: www-talk@www0.cern.ch
Content-Length: 4370

At 12:20 AM 2/2/94 -0800, David Koblas wrote:
>HTTP 1.0 example negotiating session:
>
>        Connection opened:
>                GET /index.html HTTP/1.0
>                [ batch of "Accept" and other headers sent,
>                  mosaic sends about 1K worth ]
>
>                File is sent
>        Connection closed:
>
>This is awful, since not only is there connection creation/tear down
>expenses, but also retrasmission of "client information" to the server.
>Also, since (from the survey of my server) most of the HTML documents
>are ~1K in size, it means that twice the information is being sent
>than necessary...  Not good for a slow link..

I definitely would like to see some way of doing multiple GETs with a
single connection. However, the connection costs right now aren't that
great except for the Accept. Perhaps current Accept usage should be
rethought? Several issues to consider are:
1. What are clients currently sending to servers? Lynx only sends a few
Accepts since binary information isn't displayed or manipulated, but saved
to disk. On the other hand, Mosaic for X sends approximately 1K worth.
Here's everything sent out at the start of a typical Lynx transaction.

GET /index.html HTTP/1.0
Accept: www/source
Accept: text/html
User-Agent: Lynx/2.2  libwww/2.14
From: altis@ibeam.intel.com

Other Accept examples are at the end of the message.
2. Since only gif and xbm are used for inline images shouldn't GUI clients
simply send
Accept: image/gif
Accept: image/x-xbm
when fetching <IMG SRC> inlined images? Some GUI clients actually accept
other image types for inlined images, but it is non-standard.
3. Should the transaction be reworked so that the server says I've got this
MIME type, then the client says YES or NO?
4. The number of binary image formats and binary document formats is very
large in the PC and Mac arena. Is it reasonable to assume in most cases
that the document will simply be handed off to an external browser so that:
Accept: application/*
Accept: audio/*
Accept: image/*
is the way to go rather than sending a hundred plus Accept types? The MIME
mapping application/x-excel or whatever would still get sent with the reply
so that the client can still map between the MIME type and an external
application to launch. This assumes we continue to have a central
repository for MIME types so all our x- types match across clients and
servers.

ka
---
Cello doesn't currently send Accept.

X Mosaic 2.1
Accept: text/plain
Accept: application/x-html
Accept: application/html
Accept: text/x-html
Accept: text/html
Accept: application/x-hdf
Accept: application/x-netcdf
Accept: application/hdf
Accept: application/netcdf
Accept: audio/basic
Accept: audio/x-aiff
Accept: image/gif
Accept: image/jpeg
Accept: image/tiff
Accept: image/x-portable-anymap
Accept: image/x-portable-bitmap
Accept: image/x-portable-graymap
Accept: image/x-portable-pixmap
Accept: image/x-rgb
Accept: image/rgb
Accept: image/x-xbitmap
Accept: image/x-xpixmap
Accept: image/xwd
Accept: image/x-xwd
Accept: image/x-xwindowdump
Accept: video/mpeg
Accept: application/postscript
Accept: application/x-dvi
Accept: message/rfc822
Accept: application/x-latex
Accept: application/x-tex
Accept: application/x-texinfo
Accept: application/x-troff
Accept: application/x-troff-man
Accept: application/x-troff-me
Accept: application/x-troff-ms
Accept: text/richtext
Accept: text/tab-separated-values
Accept: text/x-setext
Accept: */*

Windows Mosaic 1.0
Accept: application/pdf
Accept: application/x-frame
Accept: audio/x-midi
Accept: application/x-rtf
Accept: video/msvideo
Accept: video/qtime
Accept: video/mpeg
Accept: image/jpeg
Accept: image/gif
Accept: application/postscript
Accept: audio/wav
Accept: text/plain
Accept: text/html
Accept: audio/x-aiff
Accept: audio/basic

Mac Mosaic 1.0.3
Accept: text/plain
Accept: application/x-html
Accept: application/html
Accept: text/x-html
Accept: text/html
Accept: text/richtext
Accept: application/octet-stream
Accept: application/postscript
Accept: application/mac-binhex40
Accept: application/zip
Accept: application/macwriteii
Accept: application/msword
Accept: image/gif
Accept: image/jpeg
Accept: image/x-pict
Accept: image/tiff
Accept: image/x-xbm
Accept: audio/x-aiff
Accept: audio/basic
Accept: video/mpeg
Accept: video/quicktime
Accept: application/macbinary
Accept: application/pdf
Accept: */*