- From: koen holtman <koenh@fatima.dds.nl>
- Date: Tue, 4 Jun 1996 01:38:45 +0200 (MET DST)
- To: jg@w3.org
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Jim,
Your response to my message addressed most of my concerns about the
text in section 12. There are still some important concerns left,
however. I repeat most of them below, and will repeat the rest when I
have more time (it is 1.30 am now).
I won't discuss the comments on my comments about why section 12 is
subtly wrong. Getting a shared understanding of this is not very
important, and would take too long anyway.
My most serious concern left is that the spec requires Vary on
uncachable responses. I thought you said in Thursday's phone
conference that you would change this MUST to a SHOULD, but your
response seems to indicate you won't.
====
[spec:]
>>>content negotiation
>>> The mechanism for selecting the appropriate representation when
>>> servicing a request, as described in section 12. Note that response
>>> messages may be negotiated, as well as resources.
>>
[koen:]
>>This last sentence is confusing. I suggest that this sentence is
>>deleted.
>
[jim:]
>I think the fact that responses in general are negotiable is
>worty of note. See if this sentence does better
>
>Note, therefore that responses of all sorts can be negotiated
>(including error responses), as well as entities derived from
>resources.
Better, but I agree with Roy that deleting the sentence is best.
======
[spec:]
>>>Server-driven negotiation is advantageous when the algorithm for
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
[koen:]
>>I suggest that the start of this paragraph is rewritten so that
>>negotiation of error responses is also covered. New text:
>>
>> Server-driven negotiation can be used for selecting the
>> representation of an error response, and also for selecting the
>> representation for a successful response. When selecting the
>> representation to be used in a successful response, server-driven
>> negotiation is advantageous when the algorithm for ...
[jim:]
>The real bug is the definition of representation, which I don't think
>Roy dealt with properly.
No, this matter is orthogonal to my problem. The problem my new text
intends to solve is that the old text implies that server-driven
negotiation is only useful for selecting error response
representations in _some_ cases. This is misleading because it
implies that agent-driven negotiation is usable for error responses,
while it is not.
====
[spec:]
>>>3. It significantly complicates the implementation of an origin server
>> ^^^^^^^^^^^^^
>>> and the algorithms for generating responses to a request.
>>
[koen:]
>>I think that `significantly' should be removed: even if it were true
>>that there would be significantly more complicated, we would not want
>>to say it.
You did not comment on this one.
======
[spec:]
>>>HTTP/1.1 origin servers MUST include an appropriate Vary header field
>> ^^^^^^
[koen:]
>>Delete `origin', as discussed above.
>
>Aren't Vary headers passed through?
Yes, but that is not the point.
> I don't think that caches
>should add them by themselves; I believe Roy is right here.
The spec text is wrong here. Caches add them by themselves when
generating the response by themselves. A proxy selecting the language
for the text in a 504 error message generates its response without
contacting the origin server, and MUST include an appropriate Vary
header field.
========
[spec:]
>>>HTTP/1.1 origin servers MUST include an appropriate Vary header field
>>>(section 14.43) in any response based on server-driven negotiation. The
>> ^^^
[koen:]
>>insert `cachable', as discussed in earlier messages.
>
[jim:]
>Negotiation needs to be signalled on all responses, not just
>cacheable ones.
It MUST be signaled on cachable responses else caches might break the
negotiation, but only SHOULD be signalled on uncachable ones. Jeff
has already supplied the correct words for this in
<9605302328.AA20694@acetes.pa.dec.com>:
An HTTP/1.1 server MUST include an appropriate Vary header field with
! any cachable response that is subject to server-driven negotiation.
! Doing so
allows a cache to properly interpret future requests on that resource
and informs the user agent about the presence of negotiation on that
! resource. An HTTP/1.1 server SHOULD include an appropriate Vary header
! field with a non-cachable response that is subject to server-driven
! negotiation, since this might provide the user-agent with useful
information
! about the dimensions over which the response might vary.
> I think it correct as written.
This requirement in pre-04 is disastrous as written, because
a) it requires people who generate uncachable responses to understand
section 12
b) section 12 cannot be understood without thinking about the
effect of Vary on the caching of your response
c) b) this will drive the people under a) up the wall
d) as a result of c), we could have serious problems introducing
content negotiation
e) the spec should never use a MUST unless absolutely necessary for
the correct functioning of the protocol. The protocol can
function correctly even if user agents don't always get a Vary on
an uncachable error response that happened to have some
customization.
My earlier statement that the problems with section 12 would probably
not threaten interoperability _is only valid under the assumption_
that vary will not be required for uncachable responses.
If Vary remains required for uncachable responses, the draft is
completely unacceptable to me as a proposed standard, and will remain
unacceptable to me until all jarring near-truths, subtle internal
contradictions, and omitted rulings on interaction with other protocol
features I found in section 12 are resolved by a rewrite.
===
[spec]
>>>Vary header field describes the dimensions over which the response might
>>>vary (i.e., the dimensions over which the origin server picks its "best
>> ^^^^^^
[koen]
>>Delete `origin', as discussed above.
>
[jim]
>See above.
See above.
====
Koen.
Received on Monday, 3 June 1996 16:44:48 UTC