Message-Id: <188.8.131.52.19990213123853.0344baf0@localhost> Date: Sat, 13 Feb 1999 12:38:53 -0500 To: email@example.com From: Koen Holtman <Koen.Holtman@cern.ch> (by way of Henrik Frystyk Nielsen <firstname.lastname@example.org>) Subject: Re: Last Call: HTTP Extension Framework to Proposed Standard To the IESG: This is to notify you of the current status of the situation around draft-frystyk-http-extensions-02. My main problems with it have not been resolved by Henrik's recent reply to my last call comments. We are trying to resolve things in private e-mail, but I can't tell yet whether we will actually converge. It is quite possible that, when Henrik releases the next draft, it will not resolve all my comments. I won't post a detailed reply to Henrik's comments on my comments here, at least not right now. Replies to some parts are below. Henrik Frystyk Nielsen: >Koen Holtman: [....] >>By allowing for cachable extended responses, the spec opens up a >>rather large can of worms. Below I have identified several places >>where the spec does not handle these worms with sufficient care, but >>my list is probably not complete. In my opinion this stuff should be >>fixed by avoiding the problem all-together, i.e. by simply making all >>extended responses uncachable, and making sure that extended requests >>can never be responded to by a plain HTTP/1.x cache. > >That would certainly be one solution, however, I think it would be >unfortunate to propose an extension mechanism to a protocol that short >circuits the several years of detailed caching design that has been going >on in HTTP/1.1. As you know I was heavily involved in these `several years of detailed caching design' in HTTP/1.1. I can tell you that correctness was a major goal and that you are breaking it in several places. You have a choice between two options: either you specify a correct and simple caching discipline, or you do a lot of more work and specify a correct and subtle one with slightly better performance. The discipline you specify now is incorrect: it does not contain the necessary elements needed if independently developed extensions are to reconcile their caching needs without error, and it specifies some other necessary elements a wrong or overly simplistic way (like the 'include a Cache-Control' in section 9). This incorrect discipline will lead to all kinds of breakage and is therefore simply unacceptable. If you don't believe things will break then try some implementation experiments with multiple mandatory extensions in several cascaded proxies, with all these extensions attaching some dynamic information to the response which will become stale at different rates. Oh yes, the exact nature of the information added depends of course on the parameter headers sent with the extension requests, and the origin server which you are contacting contains resources which require different caching disciplines, with some of the resources being accessible only if a payment extension is used. Your user agent sends a request with an if-none-match header whenever it revalidates a stale response. The proxy chain contains some plain 1.1 proxies too, and you try adding some 1.0 ones if you feel lucky. You can look at protocol extensions like RFC2227 and RFC2295 to find some of the things which are needed to safely extend HTTP if caching gets involved. Your job is even bigger because you are writing a meta-protocol to co-ordinate unspecified extensions! [...] >>- Sec 5 point 3: >> >> 3. If 2) did not result in a 510 (Not Extended) status code, then >> strip the "M-" prefix from the method name and process the >> remainder of the request according to the semantics of the >> extensions and of the existing HTTP method name as defined in >> HTTP/1.1  or later versions of HTTP. >> >>This implies that a proxy which has processed an end-to-end mandatory >>extension should _not_ strip the existing Man header in the request >>when forwarding the request towards the origin server (when >>'processing the remainder according to the semantics of the existing >>HTTP method name as defined in HTTP/1.1'). Not stripping the header >>is of course wrong. If the proxy adds its own M- extension to the >>outgoing request without stripping the processed Man header first, >>this will cause the ultimate recipient of that extension to process >>the old Man extension again. This will have fun effects especially if >>the extension is for a payment protocol. > >The algorithm that you refer to says nothing about how to *forward* a >mandatory request [...] It talk about 'processing the remainder', and this can mean forwarding in a proxy, so yes, it does talk about forwarding, and tells us that the M- should be stripped in this case. [...] Therefore, I think the text is exactly correct in that >it doesn't make the assumption you infer, namely that the only right way >is to strip the extension. Yes, the text does not say that you should strip the extension. My point is that *the text is wrong in not saying this*. Above I describe a scenario where the lack of this stripping requirement leads to trouble because the extension is invoked two times. You should either a) explain why this scenario cannot happen, or b) explain why I am incorrect in my assesment that the protocol is broken if this scenario can happen. [...] >>- 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. > >This has in fact little to do with the extension framework. What you are >questioning is the basic notion of scope in HTTP/1.1. No, this has nothing to do with scope in HTTP/1.1, I am perfectly happy with the basic notion of scope in HTTP. To address my concern above you should either a) explain that I am wrong in saying that 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. or b) explain why I am wrong in my reasoning that this 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. Koen.