RE: Two-phase sends

>----------
>From: 	koen@win.tue.nl[SMTP:koen@win.tue.nl]
>Subject: 	Re: Two-phase sends
>
[omissions...]
>
>a.1) The issues list says:
>
>Two Phase methods: 
>         JM Section 8.4 POST
>         Two-phase POST removed
>         ^^^^^^^^^^^^^^^^^^^^^^
>         Mogul has writeup of result of discussion?
>         Status: need writeup, WG review 
>
>and I clearly remember that we indeed conclude that two-phase methods
>should not be in 1.1 at the end of the two-phase wars some months ago.

What's in section 8.4.1, while still labeled "two phase" is quite
different than the original two phase -- the original was pessimistic,
and this one is optimistic.
>
>a.2) Also, the 02 draft says:
>
>      POST requests must obey the entity transmission requirements set
>      out in section 8.4.1 [which talks about two-phase].
>
>While the 01/00 drafts said:
>
>   HTTP/1.1 allows for a two-phase process to occur in accepting and 
>   processing a POST request. If the media type of the posted entity 
>   is not "application/x-www-form-urlencoded" [5], an HTTP/1.1 client 
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  
>   must pause between sending [....]
>
>This considerable change was not discussed.

See below -- the removal of performance penalties in all normal cases
>made it unnecessary to make an exception for form data.
>
>Ad b:
>
>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.

RTFM. It does not say this. It says that IF THE CLIENT SEES THE
CONNECTION CLOSE WITHOUT ANY STATUS INDICATION that it has to go into
two phase mode. Before that, it can try the HTTP/1.0 style PUT or POST,
with the added requirment that it is obliged to monitor the connection
for errors and stop sending if if gets one. Hence, there will normally
be no performance penalty.
>
>b.2) The new requirement that two-phase is also used for normal POSTS
>of small forms means degradation of performance for many existing
>forms applications when upgraded to 1.1.  It may also decrease my
>chance of making a successful POST transaction (with a busy search
>engine) if the backbone is dropping a significant number of packets.

I think the response for b.1 covers this case as well.
>
>b.3) Finally, the MUST/SHOULD text about two-phase does not take
>proxies, especially 1.0 proxies, into account.

Yes it does. Read the definitions of "client" and "server". A proxy is
both a client and a server; the rules for clients and servers in 8.4.1
apply unchanged to proxies in their role as client or server. E.g.: A
1.1 user agent talking to a 1.0 proxy won't use two phase, as 8.4.1 only
applies to 1.1 clients talking to a 1.1 server. Ditto for a 1.0 proxy
talking to a 1.1 server.
>
>If I am to agree with two-phase staying in, I would require all points
>above to be convincingly addressed.

Well, I tried.

Paul
>
>

Received on Thursday, 25 April 1996 10:46:26 UTC