Re: Looking for comments on the HTTP Extension draft

Henrik Frystyk Nielsen:
>
>At 13:42 1/5/99 +0100, Koen Holtman wrote:
[...]
>>I guess there is a common theme in my Vary and 304 comments and your
>>responses: I want things to be more obvious, and you are saying that
>>things are obvious enough already.  I believe that the current draft,
>>if used as a basis for implementations, will quite likely lead to
>>implementations which have subtle caching related problems.  You may
>>say that this is a fault in the implementers, who should have known
>>the pitfalls in HTTP caching better, but I say this is a fault in the
>>draft.
>
>It's actually more a question of specification independence.

No, it is a question of whether your spec is clear enough.

> Anybody can
>extend HTTP/1.1 - and while doing that they may run into the problem of how
>to handle 304 messages. This is not unique to the extensions draft. The
>important thing to note is that the extension draft doesn't invalidate
>existing HTTP/1.1 behavior and so if you follow HTTP/1.1 rules, you should
>be safe.

Yes, the special status of 304 will be a problem in many HTTP
extensions implementations, but that does not mean that you can just
remain silent about it in your particular extension spec.  If we had
some generic document which discussed the problem in a generic way,
you could get away with just referencing that document in your spec,
but there is no such document.

>>I would be far happier if the draft dropped the examples with cachable
>>responses and replaced it with a discussion of one fail-safe method of
>>making sure that interference from caches is avoided.  I would not
>>care if the method was not very cache-friendly, expert implementers
>>could figure out more cache-friendly methods for themselves.
>
>Before doing that I would like to understand what you think is wrong with
>the current model and how that affects caching. 

I don't think there is anything wrong with the extension mechanism
itself, I just think that the current examples are not very good.
They steer implementers in a certain direction (making responses
cachable) without mentioning the pitfalls along the way.  I'd rather
see clear instructions on how to follow a safe path.

>Sorry for being slow but I
>really don't think this belongs in the extension draft.


[...]
>>If mandatory means 'this request must result in an action by the
>>origin server but a fresh response from a cache is OK too' then we
>>are talking about a different type of extension mechanism I think.
>
>Nope, it wants some action to be performed by a server which is authorized
>to and capable of handling the request.

The trouble is that if the client sends the request from table 3 a
second time before the previous response has expired:

 Client issues a     M-GET <some-address> HTTP/1.1
 request with one    Opt: <ext-1>
 optional and one    Man: <ext-2>
 mandatory           ...
 extension

then an intermediate cache may return the fresh response 

 HTTP/1.1 200 OK
 Cache-Control: max-age=120, no-cache="Ext"
 Age: 123
 ...
 [Note no Ext: in the response!]

in which case *no* mandatory action has been performed by an
authorised and capable server.  If it wanted to make sure that such an
action would be performed, the client would have to send

 M-GET <some-address> HTTP/1.1
 Opt: <ext-1>
 Man: <ext-2>
 Cache-Control: no-cache

but this is not apparent from your examples.  So either the client in
the example is not really interested in having the action performed,
or the example shows a broken way of controlling the caches.

> The opening statement in section 5
>clearly defines this:
>
>        A server MUST NOT claim to have fulfilled a mandatory request
>        unless it understood and obeyed all the mandatory extension
>        declarations in the request. This section defines a
>        mechanism for conveying this information to the client in
>        such a way that it interoperates with existing HTTP
>        applications.
>
>Note that it doesn't say "origin server" but any server.

So the second 'end' in the man 'end-to-end' declaration does not mean
the origin server?  This is not at all clear to me from reading your
spec.  In HTTP/1.1 'end to end revalidation' means revalidation which
goes through to the origin server, so I was assuming that an
'end-to-end' declaration also goes through to the origin server.  The
above quote talks about both end-to-end and hop-to-hop, so it does not
contradict the assumption that end-to-end always means to the origin
server.


>Henrik

Koen.

Received on Friday, 15 January 1999 08:21:06 UTC