Re: Performance analysis questions

Andrew Payne <>
Date: Sun, 15 May 1994 16:01:14 +0200
Message-id: <>
Precedence: bulk
From: Andrew Payne <>
To: Multiple recipients of list <>
Subject: Re: Performance analysis questions 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

Daniel Connolly writes:

>HTTP is not Internet Mail. HTTP is a protocol based on a reliable byte
>stream, such as TCP. A reliable byte stream does not munge
>whitespace. It doesn't lose characters because it translated to EBCDIC
>and back.
>HTTP is not for the human eye: it's for a piece of software that groks
>TCP (or perhaps some other reliable transport eventually...).

I agree 100%, and this raises an important point for implementors:  "be
conservative in what you send, but liberal in what you accept."

Specifically, implementations should NOT assume that the far end is 
strictly conforming to the standard.  Failure to do so can result in 
nasty surprises and *security holes*.  This is a good place to invest
in defensive programming.

As an example, here's NCSA's HTTPD code for parsing '%' escaped sequences 
in URLs and arguments (sorry to pick on you again, Rob):

    for(x=0,y=0;url[y];++x,++y) {
        if((url[x] = url[y]) == '%') {
            url[x] = x2c(&url[y+1]);

This code assumes that the '%' is always followed by two characters.  If it 
isn't (i.e. the '%' is one of the last two characters in the string), the 
loop will jump past the null at the end of the string.  The result is a 
garbage error message, a core dump, or worse, the beginnings of a 
stack-overwriting security hole.  Try typing "GET %" at your server 

>It is not the case that there are 1000s of broken HTTP implementations
>out there that we need to support. There are perhaps 10 or 20, with 2
>or 3 represending 99% of the traffic.
>Let us keep the HTTP protocol clear and free of such kludgery.

One of the best ways to enforce standard implementations is to have a good 
test suite that checks for conformance.