Re: Fast HTTP - a hyper-text transfer protocol for tommorows networks.

Paul "S." Wain <Paul.Wain@brunel.ac.uk>
Errors-To: listmaster@www0.cern.ch
Date: Thu, 30 Jun 1994 15:06:01 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9230.9406301300@cook.brunel.ac.uk>
Errors-To: listmaster@www0.cern.ch
Reply-To: Paul.Wain@brunel.ac.uk
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Paul "S." Wain <Paul.Wain@brunel.ac.uk>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Fast HTTP - a hyper-text transfer protocol for tommorows networks.
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset=US-ASCII
Content-Type: text/plain; charset=US-ASCII
Mime-Version: 1.0
Mime-Version: 1.0
X-Mailer: ELM [version 2.4 PL21]
X-Mailer: ELM [version 2.4 PL21]

@ Subject: Fast HTTP - a hyper-text transfer protocol for tommorows networks.
@ 
@  I haven't had time to write this up properly, as I've been
@ working getting the BGI based server working properly with Slow HTTP :-); 
@ there's been some interest shown, so I figured I'd post a sketch description,
@ plus the working draft of the ASN.1. 

Hi,

Bear with me on this one again. I have a few questions on this...

@ It probably won't make much sense to anybody yet, but it should become
@ clearer over time.

Having read all this I started thinking that it sounded good, but then I
realised that we are talking in an ASN.1 environment. So my question is
really;

>From the start HTTP was kept quite simple. To the extent that anyone
with a small bit of C/perl experience can write their own server. All
connections are done with 8bit chars, in a human readable way.
Okay so it isnt the fastest way, but it is more efficient to my eyes
than say FTP.

Why then should we change this and move over to ASN.1? I must confess
that having the ASN.1 specs on my desk, and trying to look something up
in them once, that I gave up and created a workaround (based on the code
in ISODE8.0 infact). The thing is that for something like "text/html" why
do we need ASN.1 headers? Or for GIF/JPEG for that matter. Okay in a
model like say X.500 when multiple attributes are being passed in one
go they make sense, but in a model such as this one, where the average
connection is to pass one page of text and say 2 images its a bit
extreme. Not to mention the text based browsers who just need one page
of text and are done with it. Look at the additional overhead there.

I for one can see more of an advantage of the model we have now, with
say mime mulitipart message bodies, if only because it is so simple, and
also makes testing of the server easy. (How many people can say they
havent telneted to a server and done a manual "HEAD / HTTP/1.0" in order
to test it or find out the servers version quickly... from the model you
are proposing we would need specialist tools to do that if I get it
right).

Looking at the tone of all that I guess it sounds very ANTI ASN.1, so
please dont get me wrong; Im not against ASN.1 in the right place. I
just think that it is very much overkill in this case. I would much
rather stay with a human readable protocol with full MIME extensions.

Paul
.-------------------------------------------------------------------------.
|_______Paul_S._Wain,_(X.500_Project_Engineer_and_WWW/HTTP_chappie),______|
| Computer Centre, Brunel University, Uxbridge, Middx., UB8 3PH, ENGLAND. |
|___VOICE:_+44_895_274000_extn_2391_______EMAIL: Paul.Wain@brunel.ac.uk __|
|                 http://http2.brunel.ac.uk:8080/paul/                    |
`-------------------------------------------------------------------------'