Subject: [Technical Errata Reported] RFC7232 (5236)

From: RFC Errata System <[email-masked]>
Date: Tue, 16 Jan 2018 07:51:24 -0800 (PST)

The following errata report has been submitted for RFC7232,
"Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5236

--------------------------------------
Type: Technical
Reported by: Chris Pacejo <[email-masked]>

Section: 2.1

Original Text
-------------
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.

Corrected Text
--------------
Likewise, a validator is weak if it is shared by two or more
representations of a given resource at the same time, even if 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.

Notes
-----
This paragraph (and only this paragraph) seems to be in direct conflict with this earlier text from the same section:

"However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the [strong] validator to distinguish those representations."

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7232 (draft-ietf-httpbis-p4-conditional-26)
--------------------------------------
Title               : Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
Publication Date    : June 2014
Author(s)           : R. Fielding, Ed., J. Reschke, Ed.
Category            : PROPOSED STANDARD
Source              : Hypertext Transfer Protocol Bis APP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Jan 2018 17:10:26 +0100

On 2018-01-16 16:51, RFC Errata System wrote:
> ...

That indeed seems to be an inconsistency.

Roy?

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 16 Jan 2018 11:33:34 -0800

> On Jan 16, 2018, at 7:51 AM, RFC Errata System <[email-masked]> wrote:
> 

This (in Notes) is referring to cases such as text/plain and application/json being two different
media types for what could be the exact same octets. Since a strong validator only
refers to the body data, a server would need to add more info to the validator
to cause clients to distinguish between those two representations.

The Original Text is about weak validators, which don't even require that
the content be the same. The two do not conflict.  The suggested change would be incorrect.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 16 Jan 2018 13:25:44 -0800

> On Jan 16, 2018, at 12:34 PM, Chris Pacejo <[email-masked]> wrote:
> 
> Hi Roy and Julian, thanks for the replies.
> 
>> On Tue, Jan 16, 2018, at 2:33 PM, Roy T. Fielding wrote:
> The specific text which confuses me, from the section on weak validators, is (emphasis mine):
> 
> "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."
> 
> Am I misunderstanding that this is in conflict with the example you gave?  (text/plain and application/json representations with same octets must have different strong validators.)
> 
> Similarly:
> 
> "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."
> 
> The "unless" clause would appear to apply to the example you gave, implying that both representations can have the same validator but need not be weak.

Yes, it does in both cases. The only distinction between weak and strong validation is that strong can be used for partial updates of the body. That’s why the metadata doesn’t matter. If the server wants the metadata to matter, it has to construct a validator (etag) accordingly to be better than just strong.

....Roy

---

From: Chris Pacejo <[email-masked]>
Date: Tue, 16 Jan 2018 20:35:11 +0000

Similarly:

Thanks, Chris

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 17 Jan 2018 23:28:09 +1300

On 17/01/18 10:25, Roy T. Fielding wrote:
> 
>> On Jan 16, 2018, at 12:34 PM, Chris Pacejo wrote:
>>

If a visualization helps, it is a 2x3 grid of possibilities:

  ...... | meta    | representation |
  weak   | varies  | varies         |
  strong | varies  | fixed          |
  better | fixed   | fixed          |

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 29 Jan 2018 12:00:06 +1100

FWIW, I think the source of confusion here is taking this statement out of context:

"""However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the validator to distinguish those representations."""

The complete paragraph is:

"""There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change to a representation always results in a unique node name and revision identifier being assigned before the representation is made accessible to GET. A collision-resistant hash function applied to the representation data is also sufficient if the data is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation request is received. However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the validator to distinguish those representations."""

I.e., the statement is being made in the context of generating strong validators based only upon the message body, when the headers might also change.

Cheers,

> On 17 Jan 2018, at 7:34 am, Chris Pacejo <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/