[6778] in www-talk@info.cern.ch
Re: More on HTTP-NG timings
daemon@ATHENA.MIT.EDU (Simon E Spero)
Tue Nov 22 18:04:42 1994
Date: Tue, 22 Nov 1994 23:45:50 +0100
Errors-To: listmaster@www0.cern.ch
Reply-To: ses@tipper.oit.unc.edu
From: Simon E Spero <ses@tipper.oit.unc.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
David -
Adding the MGET and multi-connection extensions on top of HTTP 1.0 still
leads to a dual stack apparoach - you can't leverage the existing code to
implement the extensions - you need to build the packetisation protocols
from scratch. Implementing the ascii based packetisation protocols is
much harder that implementing something like SCP. Because all the control
information is variable length, reading the control information and buffering it
is much harder than for a fixed length header. One example of this problem you
might have encountered comes in dealing with post requests (esp. with CGI).
When you read the header, you'll almost certainly end up with some of the
request data in your buffer. This data has to then be passed through to the
CGI process, along with the reset of the data that may still be in the pipe.
Another problem with the HTTP style of encoding can be seen if you try
writing an event based server. Because you can't tell if you've finished
reading a request until you've hit the newline. Because the request can
span multiple reads, you need to keep track of a lot of parser state in a
way that lets you continue when more data arrives.
The backwards compatibility mode for HTTP-NG currently starts off each
conection with a short header that will trigger method unknown from old servers.
If this were changed to be the HTTP/1.0 version of the first request (if such
a translation is possible, the level of backwards compatibility would be
identical.
The advantage of using a fixed header is that it avoids having to try and parse
a variable length header. The disadvantage is that the need to retry the
connection the first time that a particular host is encountered (after that,
the protocol of that host is cached)
It's even possible to use HTTP 1.0 syntax within SCP packetisation to get
some of the performance win - however, this approach doesn't address issues
like negotiation and charging, and still leaves you with all the headaches of
parsing the ad-hoced syntax.
Simon
