- From: Koen Holtman <koen@win.tue.nl>
- Date: Thu, 25 Apr 1996 17:14:48 +0200 (MET DST)
- 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
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
Koen.
Received on Thursday, 25 April 1996 08:21:03 UTC