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 14:58:39 UTC