Re: Content encoding problem...

Bunch of stuff I agree with deleted (nice summary, Jeff)...

>So here's what I think is the right solution:
>	(1) If there is only one representation available
>	at the server, or if the server's "normal" representation
>	is encoded, then the server should send that representation.
>	(2) If there are multiple representations, and the client
>	does not specify which one it prefers (i.e., the request
>	does not include "Accept-Encoding"), then the server should
>	send the least-encoded representation available.
>	(3) If there are multiple representations, and the client
>	specifies (using "Accept-Encoding") that it is willing
>	to accept at least one of these, then the server should
>	send the "best" of these acceptable representations.
>	(4) If there are multiple representations, and the client
>        specifies (using "Accept-Encoding") a set of encodings
>	that it is willing to accept, but there is no intersection
>	between these sets, then the server should return "None
>	Acceptable".

Yep, that's basically what was in the two paragraphs I proposed.

[more stuff I don't object to ...]

>Regarding my scenario with the HTTP/1.0 proxy cache and HTTP/1.0
>client, I still think this requires the use of a special status
>code to prevent accidents (unwitting rendering of garbage).  Roy
>can hope that people will replace their HTTP/1.0 proxies and
>HTTP/1.0 browsers because "comes a point when we must recognize
>the limitations of older technology and move on", but wishing won't
>make it so.  (And I could have argued that Roy's lwpget program,
>and existing mirror clients, should be upgraded, but I don't think
>we should be making anything that works today obsolete.)

I still think that cure is worse than the disease.

Consider this: the same rationale can be made for all forms of
server-driven negotiation, wherein one or more of the representations
are only known by some browsers.  We know that this may result in
an HTTP/1.0 cache storing a response which is only good for those browsers,
and yet serving it to other browsers.  We "solved" this problem by
adding Vary.  Is it a complete solution?  No, but it is enough of a
solution so that implementers can fix the problem, update their
shared caches, or at the very least recognize that negotiation has
been performed by the origin server.

Should we now drop that and replace it with a 207 Negotiated Content
status code?  No, because although the *possibility* exists that the 
content might be stored in a cache shared by a heterogeneous set of
user agents, the reality is that most users' browsers accept the same
things, and most sites' shared caches service only a few varieties
of user agents, and thus most of the time it is preferred to cache
the response.  And, when the above is not true, the owners of that
cache are fully capable of avoiding the problem by implementing support
for the Vary header field, even if they don't support HTTP/1.1,
and the origin server is fully capable of avoiding it by setting
Expires and Cache-Control appropriately.

>At any rate, on this topic, Roy write:
>    this particular scenario only occurs if the URL in question has
>    negotiated responses based on Accept-Encoding.  It is quite
>    reasonable for the origin server to modify its negotiation
>    algorithm based on the capabilities of the user agent, or even the
>    fact that it was passed through a particular cache; I even
>    described that in section 12.1.
>I think it would be far simpler (and safer, because it's probably
>impossible to enumerate the universe of User-Agent values) if the
>server simply used my proposed 207 status code for "negotiated"
>encodings.  I.e., if the server follows my rule #3, then it sets
>207.  If the server is following rules #1 or #2, then there hasn't
>really been a negotiation, and I suppose it makes sense to cache
>the response.  Yes, in a world without any HTTP/1.0 proxy caches
>one could rely on "Vary: Accept-encoding", but it's pointless to
>expect all such caches to disappear any time soon.

I don't expect they will; I just don't consider them worthy of concern.
There are already enough reasons why a shared cache must implement the
HTTP/1.1 enhancements in order to properly service its users -- one more
won't make much difference.  If this problem was a barrier to HTTP/1.1
deployment, then I would be more concerned, but it is the opposite.

>By the way, Roy, when you write, re: my proposed 207 (Encoded Content)
>status code,
>	it breaks the distinction between the response status and
>	the payload content, which would be extremely depressing
>	for the future evolution of HTTP.
>I really have no idea what you mean by this.  Perhaps you could

Most of the response codes allow a message body to be included in
the response, and the type of that message body is defined by the

   Transfer-Encoding( Content-Encoding( Content-Type ) )

If a server decides to save network bandwidth by sending compressed
success/redirect/error messages for status codes other than 200,
does it need to be a different status code than its usual one?
Probably not, since they wouldn't be cached by an HTTP/1.0 application.
[This is much less a concern now that you have limited 207 to case (3).]

However, aside from the aesthetic issues, I am also concerned about
(admittedly buggy) user agents failing to treat the 207 as a 200.
That isn't the case with my lwpget, and Lynx, Mosaic, and Navigator
all seem to accept it fine (Navigator even caches it), but I haven't
tested beyond that.  206 was not a concern because it was only
triggered upon receipt of a Range field in the request.

Given that the 207 code would exist solely for the purpose of busting
an HTTP/1.0 cache, wouldn't it make just as much sense to say

    Note: If the origin server is concerned about the possibility
    of an old HTTP/1.0 shared cache saving the negotiated response
    and serving it to other user agents that do not accept that type
    and/or encoding, then the origin server can include an Expires
    field with a value equal to the Date field in order to prevent
    caching of the response.  If it is desired that the response
    remain cachable for HTTP/1.1-compliant applications, then the
    origin server should also add a Cache-Control field with an
    appropriate "max-age" value.

That would accomplish the same task as a 207 in case (3), but would
not add clutter to the response codes, and the practice can be ended
when there are no HTTP/1.0 shared caches left in the world (or at least
that part of the world which is significant to the origin).

Besides, whereas there is almost no chance that the suggested 207 code
will be implemented in the HTTP/1.1 servers that will be shipped this
month, the ability to do what I describe above is already present
in servers like Apache 1.2b, and we avoid a significant change to
the requirements of an HTTP/1.1-compliant server.


Received on Friday, 21 February 1997 21:14:57 UTC