Re: Last Call: HTTP Extension Framework to Proposed Standard
From: by way of Henrik Frystyk Nielsen (Koen.Holtman@cern.ch)
Date: Mon, Mar 29 1999
Message-Id: <3.0.5.32.19990329134115.0342abc0@localhost>
Date: Mon, 29 Mar 1999 13:41:15 -0500
To: ietf-http-ext@w3.org
From: Koen Holtman <Koen.Holtman@cern.ch> (by way of Henrik Frystyk Nielsen <frystyk@w3.org>)
Subject: Re: Last Call: HTTP Extension Framework to Proposed Standard
Dear IESG,
In my earlier last call comments to
draft-frystyk-http-extensions-02.txt I advised against the 02 draft
going to proposed. After that there was a long private e-mail
exchange between Henrik and me in which we managed to resolve most of
my 02 last call comments. The 03 draft has just been released so here
is a status update from my side.
The 03 draft has fixed most of my problems with the 02 draft, and I
have no objections against the 03 draft moving forward to proposed.
On the other hand, I am not actively encouraging that it moves
forward, I am neutral on the matter of moving.
I do not plan to use the http-extensions mechanism myself, my main
interest in reviewing it has been to make sure that its users would
not break caching for me as a HTTP/1.1 user. I believe that the 03
spec has lowered the risk of bad caching interactions to an acceptable
level, so I see no reason for me to be against its deployment anymore.
Two of my 02 last call comments have not been resolved in the 03
draft, but I can live with that. For reference I list these two
comments below.
The first comment, cut-and-pasted from my earlier message:
|- Sec 5 point 4:
|
| A server MUST NOT fulfill a request without
| understanding and obeying all mandatory extension
| declaration(s) in a request.
|
|This implies that a request cannot contain two mandatory extensions
|which are to be executed by different upstream servers. For example,
|if I want my browser to send a mandatory extension to my firewall
|proxy to enable some privacy processing, I cannot at the same time use
|a browser plugin which sends a mandatory extension to trigger some
|plugin-related functionality in the origin server. Not being able to
|combine two extensions in this way is a rather severe restriction
|which kills the whole protocol for me. It means that plugin vendors
|cannot use the protocol for fear of proxies getting in the way, and
|that proxy vendors cannot use the protocol for fear of plugin vendors
|getting in the way. Result: nobody can use it.
|
|The Ext: mechanism should be fixed to solve this problem, e.g. the
|Ext: header should include the names of the extensions that were
|understood and obeyed by different upstream servers.
With respect to my suggestion for a fix above: I now believe that a
better way of fixing this would be to simply forbid proxies to fulfill
end-to-end mandatory requests.
The above comment is really about usability of the spec, not about its
internal correctness. As I do not consider myself to be a likely user
of the spec, I can live with this comment not being resolved.
The second unresolved comment:
|- Sec 5.1 Fulfilling a Mandatory Request
|
|There is no equivalent material on how to fulfill an optional request.
This is mostly an editorial nitpick, and I don't care much that it has
not been resolved.
Koen.