You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Henrik Frystyk Nielsen <fr...@w3.org> on 1998/12/17 19:38:44 UTC
Looking for comments on the HTTP Extension draft
If this is totally out of place then sorry - however, I would love to hear
what you think (both spec and implementation wise) about the HTTP extension
draft:
ftp://ftp.ietf.org/internet-drafts/draft-frystyk-http-extensions-01.txt
Keith Moore has asked for reviews before considering moving it to proposed
as there it is not the work of a working group but an individual submission.
Some of you including Roy already know about this draft - if you have
further comments then now is a really good time to speak up! Comments
should go to <di...@apps.ietf.org>.
Just for the context, I have pasted his mail below so that you can see the
status.
Thanks!
Henrik
>
>X-URI: http://www.cs.utk.edu/~moore/
>X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90
>To: discuss@apps.ietf.org, web@apps.ietf.org
>Subject: need reviewers for HTTP Extension Framework
>cc: moore@cs.utk.edu
>reply-to: discuss@apps.ietf.org
>From: Keith Moore <mo...@cs.utk.edu>
>Date: Wed, 16 Dec 1998 16:52:36 -0500
>Sender: moore@cs.utk.edu
>List-Unsubscribe: <mailto:discuss-request@apps.ietf.org?Subject=unsubscribe>
>
>[Please DO NOT send replies to web@apps.ietf.org]
>
>Hi. Henrik Nielsen of W3C has asked the Apps ADs to consider
>"HTTP Extension Framework" <draft-frystyk-http-extensions-01>
>as a Proposed Standard. We haven't had time to do a detailed
>review ourselves, but we would like other folks' opinions as to
>whether this draft is reasonably complete (i.e. that it addresses
>enough aspects of the problem) and ready for standardization,
>before we do an official Last Call.
>
>As HTTP reuse is of concern to the entire Applications Area, please
>send comments to discuss@apps.ietf.org, NOT to web@apps.ietf.org
>
>The draft can be found at
>ftp://ftp.ietf.org/internet-drafts/draft-frystyk-http-extensions-01.txt
>
>Thanks!
>
>Keith
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk
Re: Looking for comments on the HTTP Extension draft
Posted by Henrik Frystyk Nielsen <fr...@w3.org>.
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
Re: Looking for comments on the HTTP Extension draft
Posted by Henrik Frystyk Nielsen <fr...@w3.org>.
At 14:53 12/18/98 +0100, Koen Holtman wrote:
>There could be some more discussion of caching related considerations, in
>particular
>
> - I would like to see and example of correct use of the Vary header
> (hinted at in 3.1)
It works exactly as for accept* headers with q-values in case you are using
ns and without q-values if not. Btw, I don't know if you have seen the
extended set of scenarios at
http://www.w3.org/Protocols/HTTP/ietf-http-ext/Scenarios.html
although they do not contain a vary example.
> - I would like explicit mention of the fact that things can break
> horribly if extensions are added to a 304 response. See
> http://lists.w3.org/Archives/Public/ietf-http-ext/1998JanMar/0105.html
> for a discussion of the problem.
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:
If the conditional GET used a strong cache validator (see section
13.3.3), the response SHOULD NOT include other entity-headers.
Otherwise (i.e., the conditional GET used a weak validator), the
response MUST NOT include other entity-headers; this prevents
inconsistencies between cached entity-bodies and updated headers.
> [On a related note: it is non-trivial to piggy-back something not
> directly related to the response body onto a HTTP/1.x response and
> have it work correctly through caches. Having it work and also be
> cache-friendly is _extremely_ non-trivial. This is one of the
> things I would like to see addressed in any future HTTP-NG/1.2/2.0
> effort]
>
>Making responses to M-GET (or other mandatory methods) cachable is
>not as simple as it looks from the examples at the end of the draft. In
>the example of 15.1, all of the proxies in the chain will cache the
>response as a response to an M-GET request, and these cannot be used to
>respond to future GET requests on the same resource.
M-GET is semantically different from GET - the difference being exactly one
or more mandatory extensions. It therefore doesn't make sense to say that a
response to a M-GET request can be cached and served to another client
issuing a GET request.
> Also, if the user
>agent would send a subsequent M-GET+Man request, it probably wants the Man
>header to reach the origin server, so it would have to include a
>Cache-Control: no-cache in its request. The only case where the cached
>response could do some good is if a proxy along the chain transforms a GET
>request into an M-GET+C-opt request, but this subtle benefit is not clear
>from the example.
Nope - by default, an HTTP client is interested in the nearest fresh
response it can get for that method. It is no different with a client
issuing a M-GET request - by default it is interested in the nearest fresh
response for that method. However, as the semantics of the M-GET method
isn't defined by the M- prefix but rather by the extension declaration, it
can only be served by a cache who knows that extension.
>With respect to the draft solving a problem, I will repeat some points
>I have made before elsewhere:
>
> - The header field prefixes stuff is just unnecessary complexity in
> my opinion. It would be easier for everyone to put all extension
> related data as decl-extensions in the Man or Opt header.
This proposal was voted down after discussion on the <ietf-http-ext>
mailing list:
http://lists.w3.org/Archives/Public/ietf-http-ext/1998AprJun/0029.html
> - If the goal is to prevent clashes between header fields invented by
> independent developers (whether inside the IETF or outside it), an
> open header field registry would be far better at achieving this
> goal. (Weren't there efforts to set up such a registry? What
> happened to them?).
HTTP extensions has no problem working with centrally registered header
fields as long as they are referencable by a URI or in the special case of
being defined by a standards track RFC.
> The barrier of entry to
> using Man/Opt with a newly invented URI will always be slightly
> higher, as one has to implement parsing of the Man/Opt headers at
> least.
The purpose of a framework is that you only have to implement it once and
then can reuse it as often you like. However, you are right that it has to
be implemented at least once but I can't see how that makes it differ from
any other feature in HTTP.
Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk
Re: Looking for comments on the HTTP Extension draft
Posted by Koen Holtman <Ko...@cern.ch>.
[...draft-frystyk-http-extensions-01...]
[....]
> >From: Keith Moore <mo...@cs.utk.edu>
[....]
> > We haven't had time to do a detailed
> >review ourselves, but we would like other folks' opinions as to
> >whether this draft is reasonably complete (i.e. that it addresses
> >enough aspects of the problem) and ready for standardization,
> >before we do an official Last Call.
As far as I can see the draft is reasonably sound as an extension to HTTP.
Some more discussion of caching implications is needed though.
There could be some more discussion of caching related considerations, in
particular
- I would like to see and example of correct use of the Vary header
(hinted at in 3.1)
- I would like explicit mention of the fact that things can break
horribly if extensions are added to a 304 response. See
http://lists.w3.org/Archives/Public/ietf-http-ext/1998JanMar/0105.html
for a discussion of the problem.
[On a related note: it is non-trivial to piggy-back something not
directly related to the response body onto a HTTP/1.x response and
have it work correctly through caches. Having it work and also be
cache-friendly is _extremely_ non-trivial. This is one of the
things I would like to see addressed in any future HTTP-NG/1.2/2.0
effort]
Making responses to M-GET (or other mandatory methods) cachable is
not as simple as it looks from the examples at the end of the draft. In
the example of 15.1, all of the proxies in the chain will cache the
response as a response to an M-GET request, and these cannot be used to
respond to future GET requests on the same resource. Also, if the user
agent would send a subsequent M-GET+Man request, it probably wants the Man
header to reach the origin server, so it would have to include a
Cache-Control: no-cache in its request. The only case where the cached
response could do some good is if a proxy along the chain transforms a GET
request into an M-GET+C-opt request, but this subtle benefit is not clear
from the example.
In short I would call the example in 15.1 misleading. Rather than examples
encouraging people to put Cache-Control in M-GET responses, I would have a
discussion of the subtle failure modes involved, and some simple, not
necessarily cache-friendly, guidelines for avoiding all failure modes.
With respect to the draft solving a problem, I will repeat some points
I have made before elsewhere:
- The header field prefixes stuff is just unnecessary complexity in
my opinion. It would be easier for everyone to put all extension
related data as decl-extensions in the Man or Opt header.
- If the goal is to prevent clashes between header fields invented by
independent developers (whether inside the IETF or outside it), an
open header field registry would be far better at achieving this
goal. (Weren't there efforts to set up such a registry? What
happened to them?). The usual way for people to prototype an HTTP
extension is to hack together a CGI script which emits or responds
to a few newly invented headers. I can't see how the proposed
mechanism would change this practice. The barrier of entry to
using Man/Opt with a newly invented URI will always be slightly
higher, as one has to implement parsing of the Man/Opt headers at
least.
Koen.