Re: Solution to the CGI message trap

    Jeff's Ack response will probably work, provided you don't mind
    that none of the responses will ever be cachable.  It is hard to
    tell if anyone would want a mandatory extension to be cachable, so
    I don't know if that is good or bad.  For that matter, I have yet
    to see a scenario where mandatory extensions are needed at all that
    didn't also require some outside knowledge, perhaps obtained from a
    prior request, about the resource in question.

Actually, the Ack response seems to have been Henrik's idea, I just
suggested adding nonces.  Anyway, in the context of CGI responses,
we already have a strong expectation that these aren't usually
cached in current environments, so making them slightly harder to
cache probably won't affect things much.  (Especially if the
alternative is to make certain things simply too unreliable to
do at all.)

    OTOH, you could add a bunch of checks and double-checks to the
    mandatory stuff so that it isn't worth implementing even for the
    resources that would have understood it.  That is why perfection is
    not one of the goals of HTTP.

Perfection might not be one of the goals of HTTP, but I searched
the HTTP/1.1 spec for the first use of the word "goal", and found

    The goal of HTTP/1.1 is to support the wide diversity of
    configurations already deployed while introducing protocol
    constructs that meet the needs of those who build web applications
    that require high reliability and, failing that, at least reliable
    indications of failure.

I.e., "reliable indications of failure" is indeed one of the goals
that we seem to have agreed upon.  (I wonder who wrote that sentence?)

-Jeff

Received on Monday, 10 August 1998 14:16:16 UTC