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

Ticket #401 (closed design: fixed)

Opened 2 years ago

Last modified 18 months ago

ETags and Conneg

Reported by: mnot@pobox.com Owned by:
Priority: normal Milestone: 22
Component: p4-conditional Severity: In WG Last Call
Keywords: Cc:
Origin:

Description

I just received an interesting bug report on REDbot; <https://github.com/mnot/redbot/issues/109>

""" When an ETag is marked weak with "W/", it need not change across different content encodings. "Weak" means the entity is semantically equivalent but not bit-equivalent. But Redbot complains that it doesn't change with different content encodings. """

The obvious question is whether two different *negotiated* representations of the same resource can (or should) have the same weak ETag.

Change History

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

  • Milestone changed from unassigned to 22

Proposal:

  1. add a MUST requirement for strong ETag uniqueness, and
  2. clarify in prose that if you issue the same weak ETag for *any* two representations of a resource, you consider them interchangeable (possibly in the examples), and
  3. clarify the definition of ETags WRT "differentiate"

comment:2 Changed 23 months ago by mnot@pobox.com

  • Owner draft-ietf-httpbis-p4-conditional@tools.ietf.org deleted

comment:3 Changed 21 months ago by fielding@gbiv.com

Can you suggest prose to add near bottom of section 2.1? The current examples are all time-based. I don't think any other clarification is needed.

comment:4 Changed 21 months ago by mnot@pobox.com

Insert before the last paragraph in 2.1:

Note that any two representations of a resource that share a weak validator can be considered equivalent when using the weak comparison function; this applies even if their other metadata (e.g., Content-Type) differs.

Last edited 21 months ago by mnot@pobox.com (previous) (diff)

comment:5 Changed 21 months ago by fielding@gbiv.com

That doesn't fit with the new style of that section. I have added:

Likewise, a validator is weak if it is shared by two or more representations of a given resource at the same time, unless those representations have identical representation data. For example, if the origin server sends the same validator for a representation with a gzip content coding applied as it does for a representation with no content coding, then that validator is weak. However, two simultaneous representations might share the same strong validator if they differ only in the representation metadata, such as when two different media types are available for the same representation data.

comment:6 Changed 21 months ago by fielding@gbiv.com

From [2136]:

note that simultaneous use of the same validator for different representation data would also make it weak; addresses #401

comment:7 Changed 21 months ago by fielding@gbiv.com

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

comment:8 Changed 21 months ago by mnot@pobox.com

That reads like you're saying that a strong validator can be made magically into a weak one by associating it with two representations that have different bits.

comment:9 Changed 21 months ago by fielding@gbiv.com

Yes, that's intentional -- this section defines weak vs strong. A later section says that an entity-tag must be marked as weak unless it has all the characteristics of being strong.

comment:10 Changed 21 months ago by mnot@pobox.com

(reading in context) OK. Thx.

comment:11 Changed 18 months ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:12 Changed 18 months ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.