W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: STATUS100 Re: Proposed resolution

From: David W. Morris <dwm@xpasc.com>
Date: Thu, 17 Jul 1997 22:31:10 -0700 (PDT)
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.GSO.3.96.970717222141.26427E-100000@shell1.aimnet.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3800

On Thu, 17 Jul 1997, Jeffrey Mogul wrote:

> Responses to comments from Scott Lawrence:
>    I think that making this a special case allowed _only_ for HTTP/1.1
>    is going too far.  We already have the requirement that 100 Continue
>    must be accepted by the client anyway.  We're talking about as few
>    as 'HTTP/1.1 100CRLF" - 14 bytes - 23 if you send the ' Continue'.
>    What justification is there for the complexity of this restriction?
> See above.  But I agree with you that this is a judgement call.
> I'm just worried that we may not need to send these extra bytes,
> and we have the chance now to discourage 23*N extra bytes over
> the Internet for many years to come (where N is a large number!)

I think we have lost sight of the fact that it isn't 14 (or 23) bytes
but rather those bytes encapsulated in a packet.  The implication
to network routers and TCP/IP stacks is not linear with length.  The
routing function is more costly then the simple buffering associated
with length.  Secondly, this 100 Continue packet may require
a separate acknowledgement packet.  The assumption of at most 2
packets is based on the TCP/IP application sending the data with a
single API call, etc. I learned the hard way that sending a line
of data in one write followed by CRLF in a second is bad news as is
sending each line of the HTTP headers one per write request.

All in all the implications to the network are much greater than the
simple 23 bytes we are discussing.

Dave Morris

(FWIW ... the minimum would be:  HTTP/1.1 100CRLFCRLF or 16 bytes, 
wouldn't it?)
Received on Thursday, 17 July 1997 22:46:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC