RE: RE: NEW ISSUE: 13.1.2's Definition of 1xx Warn-Codes

Larry Masinter said:
> We're talking about
>
>  1xx  Warnings that describe the freshness or revalidation status of
>    the response, and so MUST be deleted after a successful
>    revalidation. 1XX warn-codes MAY be generated by a cache only when
>    validating a cached entry. It MUST NOT be generated by clients.
>
> ------------------------------------
> First, a few guidelines, as I remember them:
>
> * The roles of 'client', 'proxy' and 'server' were not intended to
> be exhaustive; HTTP is used in many contexts with hybrid roles
> and complex relationships. In some cases, it's necessary to
> specify requirements specifically for clients vs. proxies,
> or proxies vs. servers, but in general, it's better to couch
> things in terms of request messages and their responses.

Then the spec shouldn't require that proxies MUST implement both client and
server behaviors -- because this makes those words very normative-sounding.
In fact, I think it would be pretty hard to specify HTTP without these
delineations for a good chunk of the behaviors that are present.

> * In general, it's better to avoid MUST and MUST NOT rules except
> for those cases where it is necessary to ensure interoperability
> or operational stability. (There are a few additional cases,
> but generally not.)  It's especially troublesome to add
> "MUST" or "MUST NOT" requirements to HTTP at this time.
> We do better when we describe how things work
> and what protocol elements _mean_ and let implementors
> use them as appropriate.

That's a can of worms for another day ;).

> * More specifically, it's better to avoid specifying
> implementation advice rather than observable network
> behavior. (Again, some exceptions.)

No disagreement here.

> The introduction of MUST/MAY/SHOULD keywords happened by
> taking English text without them and introducing them
> in an editing pass, but (in my opinion) there are too many
> of them in the HTTP spec. It's better to avoid introducing
> any more.

I don't think there are too many of them, so much as they are too often
misused and/or in the wrong places. Case in point...

> -----------------
> So, I can't see what the interoperability problems would
> be, for allowing responses to contain warnings when
> responses are stale generally.

[Encompassed by my response to your final paragraph]

> My proposed rewrite:
>
>  1xx  Warnings that describe the freshness or revalidation status of
>     a response. For example, a cache might include a warning
>     if it is unable to revalidate the freshness of a cached value,
>     but would not include a warning after a successful revalidation.
>     These warnings only apply to responses, and SHOULD NOT
>     appear in request messages.
>
> I.e., avoid a too narrow (and unnecessary) MUST NOT,
> or really specifying anything other than what the
> warning means, and letting implementors decide
> when to use them.

[Encompassed by my response to your final paragraph]

> > "A cache MUST NOT generate 1xx warn-codes for any messages
> > except cache entries
>
> Let's suppose I have a web site where I generate  pages
> from a database, and I cache the database values but
> not the HTML  pages. If the database cache is stale,
> I might still want to include a 1xx warning, even though
> the response didn't correspond to a 'cache entry'.
> Why would you disallow this?

It's not disallowed; the keyword is "cache". What you're talking about is
not a protocol-level cache, and the server is free to add whatever warn-
codes it wants. This requirement applies only to the behavior of caches as
defined by the spec, and the spec clearly states that the caches it refers
to deal with storing and retrieving "response messages". Granted, we could
probably make things more explicit (and I'm all for that), but this is not
as prohibitive as you make it out to be.

> > and MUST NOT generate 1xx warn-codes for a cache entry except in
> > response to a validation attempt for that entry.
>
> I don't understand what a 'validation attempt'
> might be that isn't implicit in a 'request'.
> Is there a reason why some stale results shouldn't
> include warnings?

I sure don't know, either, but the original author thought that that wording
was important for one reason or another. Unfortunately, there is no
explanatory part for this set of requirements, so I can't tell you what the
author was thinking, or why this particular phrasing is (or at least was)
important. It could also be that I misinterpreted the original sentence that
my proposed phrasing is based on ("1XX warn-codes MAY be generated by a
cache only when validating a cached entry"). Since my goal was to make
little to no semantic change (insofar as the _actual intent_ of the spec,
not the literal interpretation), I just took that section and attempted to
make its meaning as explicit as possible; I haven't bothered to question the
semantics themselves, because that goes beyond a simple editorial change.


Thanks,

-- Travis

Received on Friday, 29 December 2006 17:43:40 UTC