* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #101 (closed design: fixed)

Opened 7 years ago

Last modified 3 years ago

Definition of validator weakness

Reported by: mnot@pobox.com Owned by: julian.reschke@gmx.de
Priority: urgent Milestone: 14
Component: p4-conditional Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/47767C72.6030507@onlinehome.de

Description

From 13.3.3 Weak and Strong Validators:

Entity tags are normally "strong validators," but the protocol provides a mechanism to tag an entity tag as "weak." One can think of a strong validator as one that changes whenever the bits of an entity changes, while a weak value changes whenever the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific entity, while a weak validator is part of an identifier for a set of semantically equivalent entities.

Note: One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed.

An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible that the resource might be modified twice during a single second.

While in paragraph 1 "weak validator" is defined in terms of semantic equivalence, paragraph 3 qualifies modification time as "weak validator". But the second modification of a file within the same second may change the file into anything. There is no means to guarantee semantic equivalence in this case. Both this paragraphs are mutual exclusive.

The reason for this is the abstraction "weak validator" itself. While "validator" is a good abstraction from the details of Last-Modified and Etag, and also "strong validator" is quite clear, this can't work for "weak".

"weak validator" tries do build a common abstraction from two different, completely unrelated kinds of "weakness".

Weak etags: the weakness is not to guarantee byte-equivalence, but they guarantee semantic equivalence. Of course, the server needs some concept of semantic equivalence build in, to use weak etags. (Oh, and it would be fine, if the client would have the same idea about semantics.)

Last-Modified date: the weakness is the limited time resolution. It is *unreliable* (or not a validator at all), unless it meets some extra conditions. There is no concept of semantic equivalence whatsoever.

On consequence are the strange restrictions on "weak validators". Clients must only use them in conditional (full body) GET requests. This is reasonable for Last-Modified (if it does not meet the additional restrictions), but not at all justified for weak etags.

The only reasonable restriction on weak etags is not to use them in range requests. But a PUT with If-Match: W/"xxx" is perfectly ok.

I suggest to remove the term "weak validator" from the spec. Validator is either a Last-Modified Date or an Etag. Etags can be strong or weak. I should be made clear, that weak etags ore only meant to validate semantic equivalence and it should be clear, that everything said about semantic equivalence is related to weak etags.

Practical issue: Apache misuses weak etags when it can not create a strong one, due to the limited time resolution (and mtime is the main component of Apache's etags). This etags will *never* match. (IIS seems to do something similar.) Although I'm sure, this is not what weak etags are intended for, one could use the inconsistent definition in the spec to justify this (one has to be either a lawyer or a programmer to do so).

I don't know, if there is any application, that uses weak etags as they are intended (for validating semantic equivalence). But if there is, or will be, the above misuse will most likely create interoperability problems. WebDAV-clients (e.g. davfs2) already have problems to work around this wrong "weak etags".

Attachments

i101.diff (1.8 KB) - added by julian.reschke@gmx.de 6 years ago.
Proposed change for part 4.

Change History

comment:1 Changed 7 years ago by mnot@pobox.com

remove the notion of "semantic equivalence" and replace it with "good enough, from the server's point of view". That is, a server is free to report a "match" on a weak validator if the server thinks an entity previously served with that validator is "good enough", from the server's point of view. Whether that's semantically equivalent doesn't need to come into the picture, except as an example of one reason why, even if something has changed, you might be content to let the client use old content.

-- http://www.w3.org/mid/002001c84d84$13e4c240$3bae46c0$@org

comment:2 Changed 7 years ago by mnot@pobox.com

Proposal:

Remove the notion of "semantic equivalence" and replace it with (roughly) "good enough, from the server's point of view".

comment:3 Changed 7 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 03

Proposal accepted.

comment:4 Changed 6 years ago by julian.reschke@gmx.de

  • Milestone changed from 03 to 04

comment:5 Changed 6 years ago by mnot@pobox.com

Suggestion:

P4, section 3:

A "weak entity tag," indicated by the "W/" prefix, MAY be shared by

two entities of a resource only if the entities are equivalent and could be substituted for each other with no significant change in semantics.

to:

... MAY be shared by two representations of a resource only if the origin server considers them to be semantically equivalent.

Section 5:

However, there might be cases when a server prefers to change the validator only on semantically significant changes, and not when insignificant aspects of the entity change. A validator that does not always change when the resource changes is a "weak validator."

Entity tags are normally "strong validators," but the protocol provides a mechanism to tag an entity tag as "weak." One can think of a strong validator as one that changes whenever the bits of an entity changes, while a weak value changes whenever the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific entity, while a weak validator is part of an identifier for a set of semantically equivalent entities.

Section 6:

In order to be legal, a strong entity tag MUST change whenever the associated entity value changes in any way. A weak entity tag SHOULD change whenever the associated entity changes in a semantically significant way.

to:

... A weak entity tag SHOULD change whenever the associated entity changes in a way that the server determines is semantically significant.

comment:6 Changed 6 years ago by julian.reschke@gmx.de

  • Owner set to julian.reschke@gmx.de

Changed 6 years ago by julian.reschke@gmx.de

Proposed change for part 4.

comment:7 Changed 6 years ago by fielding@gbiv.com

I don't see how that addresses the issue of "semantically equivalent" being an untestable quality. What it should say is

A weak entity tag SHOULD change whenever the origin server considers prior representations to be unacceptable as a substitute for the current representation. In other words, an entity tag SHOULD change whenever the origin server wants caches to invalidate old responses.

Note that this same pattern needs to be used in other cache descriptions, because 2616 mistakenly defines HTTP in terms of implementation rather than in terms of what the interface describes to the message recipient.

comment:8 Changed 6 years ago by julian.reschke@gmx.de

  • Milestone changed from 04 to unassigned

comment:9 Changed 6 years ago by ylafon@w3.org

Here is a proposed change, as the issue is more the definition of "weak validator", being linked to both unreliable identification of changes _and_ the will to signal only significant (read: semantic) changes.

Paragraph 5:

However, there might be cases when a server prefers to change the validator only on semantically significant changes, and not when insignificant aspects of the entity change. A validator that does not always change when the resource changes is a "weak validator."

Entity tags are normally "strong validators," but the protocol provides a mechanism to tag an entity tag as "weak." One can think of a strong validator as one that changes whenever the bits of an entity changes, while a weak value changes whenever the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific entity, while a weak validator is part of an identifier for a set of semantically equivalent entities.

=>

However, there might be cases when a server prefers to change the validator only on semantically significant changes, and not when insignificant aspects of the entity change, or cases where the validator is use does not allow reliable identification of changes. A validator that does not always change when the resource changes is a "weak validator".

Entity tags are normally "strong validators", but the protocol provides a mechanism to tag an entity tag as "weak". One can think of a strong validator as one that changes whenever the bits of an entity changes, while a weak entity tag value changes whenever the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific entity, while an entity tag used as a weak validator is part of an identifier for a set of semantically equivalent entities

comment:10 Changed 5 years ago by mnot@pobox.com

  • Priority set to normal
  • Severity set to Active WG Document

Julian to produce an updated patch based upon Roy's proposal.

comment:11 Changed 5 years ago by julian.reschke@gmx.de

  • Priority changed from normal to urgent
  • Status changed from new to assigned
  • Milestone changed from unassigned to 10

comment:12 Changed 4 years ago by julian.reschke@gmx.de

  • Milestone changed from 10 to 11

comment:13 Changed 4 years ago by julian.reschke@gmx.de

  • Milestone changed from 11 to 12

comment:14 Changed 4 years ago by julian.reschke@gmx.de

  • Milestone changed from 12 to 13

comment:15 Changed 4 years ago by julian.reschke@gmx.de

  • Milestone changed from 13 to 14

comment:16 Changed 4 years ago by julian.reschke@gmx.de

Looked at Part4, and this needs more cleanup. Weak etags are explained at least three times, each time with slightly differing language.

Maybe cut down the text first, and then fix what's left?

comment:17 Changed 4 years ago by fielding@gbiv.com

From [1223]:

Define "selected representation" as a shorthand for targeting conditional requests, effectively replacing the old notion of resource variants. Addresses #89.

Remove the nonsense about semantic equivalence and replace it with the mechanical reason that origin servers might not want to change a weak entity-tag on every update. Addresses #101.

Rewrite the condtional evaluation text accordingly and reduce some duplication of requirements.

comment:18 Changed 4 years ago by julian.reschke@gmx.de

From [1242]:

note that #101 was resolved by [1123] (see #101)

comment:19 Changed 4 years ago by julian.reschke@gmx.de

From [1243]:

note that #101 was resolved by [1123] (see #101)

comment:20 Changed 4 years ago by julian.reschke@gmx.de

  • Status changed from assigned to closed
  • Resolution set to incorporated

comment:21 Changed 3 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:22 Changed 3 years ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to fixed

comment:23 Changed 3 years ago by fielding@gbiv.com

From [1374]:

Clarify what should happen when a response is incomplete. Disentangle the requirements surrounding conditional range requests, strong validators, and recombining partial content to remove redundant redundancy. Separate handling of 304 responses into a separate section on cache freshening.

Add definitions for "cache entry" and "cache key". Improve introductions for caching and cache operation.

These changes should all be editorial, hopefully. Tangentially related to #101 and #304.

Note: See TracTickets for help on using tickets.