RE: PEP draft delayed -- diffs so far attached

1. I agree that defining things in terms of "persistent connections" is
a bad idea. I suspect that cookies are the best way to go here. Once a
transaction has been completed the server can send the world's shortest
cookie to use as a transaction id. I am now waiting for Larry to pounce.
=)
2. Henrik, I'm worried there may have been some miscommunication here. I
do not think the spec made the wrong choice in using the mangled method
names. I do not believe there is any realistic way to avoid it. My HTTP
2.0 comment was a lament that until that far off day comes when HTTP 2.0
is implemented, we will have to use the method mangle.

		Yaron

> -----Original Message-----
> From:	Henrik Frystyk Nielsen [SMTP:frystyk@w3.org]
> Sent:	Wednesday, March 12, 1997 2:57 PM
> To:	Yaron Goland; 'Dan Connolly'; http-wg@cuckoo.hpl.hp.com
> Cc:	khare@w3.org
> Subject:	RE: PEP draft delayed -- diffs so far attached
> 
> At 05:18 PM 3/11/97 -0800, Yaron Goland wrote:
> 
> >Also, would it be correct to assume that if one is able to
> successfully
> >transmit a PEP enhanced request and get an appropriate response then
> the
> >extension could specify, as part of its definition, that it is no
> longer
> >necessary to send the protocol header so long as the persistent
> >connection is outstanding? The idea is that protocol headers are
> quite
> >large and having to send them on every request would not be
> desirable. I
> >notice the spec hints at this with its comments regarding cookies but
> >that still is heavier than absolutely necessary.
> 
> An important property of the Protocol header is that it is a
> transaction
> header and so a PEP-enabled HTTP transaction has the same transaction
> model
> as a non-PEP-enabled HTTP transaction - that is - exactly one
> request/response. There are two reasons for this:
> 
> 1) It would be unfortunate to rely on opening and closing transport
> connections for terminating PEP extensions. One of the main
> differences
> between HTTP/1.0 and HTTP/1.1 is that you never have to close the
> connection in order to resume a well-known state. The exception is the
> "Upgrade" header which unfortunately only can be terminated by closing
> the
> underlying connection.
> 
> 2) The binding property of PEP allows the user-agent and the origin
> server
> to make a contractual agreement for the semantics of a specific
> transaction. The only way to reliably extend this agreement is by
> doing it
> explicitly, either by  repeating the agreement (sending the Protocol
> header
> again) or using cookies. If it was implicit, then this would require
> caches
> to maintain state of the transport connection and know when to apply
> which
> extensions implicitly. As there may not be a 1:1 mapping between the
> "incoming" proxy connection and the "outgoing" proxy connection then
> this
> can be very tricky.
> 
> Unless convinced otherwise then I think this makes the overall win of
> having a transport connection scope very small.
> 
> >The method name hack is truly horrific but I don't see any way around
> >that which will still work with down level agents. Even worse, the
> only
> >way to be rid of it, is to rev HTTP to 2.0.
> 
> and then you would be very alone in the world as you can't talk to any
> installed HTTP applications. This would require at least 2 RTTs in
> many
> cases - now you can settle with one (bad enough but better).
> 
> The same is of course the case for the error code - if either of the
> extensions fail then the error code is "420 Bad Extension". You then
> use
> the Protocol-Info in the response to see which of them went wrong.
> 
> Thanks,
> 
> Henrik
> --
> Henrik Frystyk Nielsen, <frystyk@w3.org>
> World Wide Web Consortium, MIT/LCS NE43-346
> 545 Technology Square, Cambridge MA 02139, USA

Received on Wednesday, 12 March 1997 16:13:36 UTC