Re: Looking for comments on the HTTP Extension draft

At 13:42 1/5/99 +0100, Koen Holtman wrote:

>I am not sure what you are saying here, I don't see the connection
>with the presence or absence of q values.  Anyway, the type of example
>I want to see is

I will add a vary example.

>>I don't think the situation you describe is any different than what can
>>happen if any header field is tagged onto a 304 response. This is the
>>reason for the restrictions on what a 304 response can contain, see
>>
>>	http://www.ietf.org/internet-drafts/draft-ietf-http-v11-spec-rev-06.txt
>>
>>section "10.3.5 304 Not Modified", where it says:
>
>I know about that restriction on 304 responses in HTTP/1.1.  But it is
>not clear from your http-ext spec whether http-ext servers and proxies
>may violate that restriction.  http-ext proxies violate 1.1 in other
>ways too, for example proxies will sometimes change the request
>method, which is not allowed under plain 1.1.

HTTP Extensions don't break HTTP - HTTP doesn't say anything about whether
a proxy can or cannot change the method. However, it is very specific on
the use of 304 and hence the rules are clear. The reason why I don't want
to define the  semantics of what can happen with a 304 message is that
HTTP/1.1 is and should be the authoritative on this issue.

>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. 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.

>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. Sorry for being slow but I
really don't think this belongs in the extension draft.

>I disagree.  If the client includes a Man header, it wants some
>action, specified by the extension in the header, to be performed by
>the origin server.  Isn't that what mandatory stands for?  If it did
>not really want the action, but would settle for a fresh response
>instead, it would have put the action in an Opt header.
>
>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 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.

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Monday, 11 January 1999 00:55:34 UTC