W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: Two-phase sends

From: Koen Holtman <koen@win.tue.nl>
Date: Thu, 25 Apr 1996 17:14:48 +0200 (MET DST)
Message-Id: <199604251514.PAA13412@wsooti20.win.tue.nl>
To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Cc: koen@win.tue.nl, jg@w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, masinter@parc.xerox.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/334
Roy T. Fielding:
>> b.1) Two-phase saves bandwidth sometimes, at the cost of speed
>> (round-trips) for each POST request, no matter how small.  I have seen
>> no statistics that this tradeoff improves current conditions, while I
>> suspect that it does not in many cases. Two-phase thus adds complexity
>> without having established the need for this.  If we have it, it
>> should at least be optional for small POST requests.
>This is simply untrue.  The two-phase mechanism does not come into play
>until AFTER the first request encountered A FAILED CONNECTION WITH RESET.

If this is the case, my problems with two-phase would mostly
disappear.  If you are right, I misinterpreted (the context of?) the
following language in the spec:

    If the client knows that the server is an HTTP/1.1 (or later) server,
    because of the server protocol version returned with a previous request
    on the same persistent connection [alternatively:  within the past <N>
    hours], it MUST wait for a response.  If the client believes that the
    server is a 1.0 or earlier server, it    SHOULD continue transmitting
    its request after waiting at least [5] seconds for a status response.

and I strongly suggest that this part is rewritten to make it more
clear when this MUST comes into play.

> ...Roy T. Fielding

Received on Thursday, 25 April 1996 08:21:03 UTC

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