Opened 6 years ago

Closed 6 years ago

#518 closed design (incorporated)

APPSDIR review of draft-ietf-httpbis-p4-conditional-24

Reported by: julian.reschke@… Owned by: draft-ietf-httpbis-p4-conditional@…
Priority: normal Milestone: 25
Component: p4-conditional Severity: In IETF LC
Keywords: Cc:

Description (last modified by julian.reschke@…)

Ray Polk:


1) This section is slightly vague:

2.1. Weak versus Strong -- "A strong validator might change for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g., Content-Type), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored responses held by remote caches"

It might benefit from clarification and an example:

clarification - "for other reasons" to "for reasons other than changes to the body"

example of a change to Contet-Type that wouldn't result in change to the body (e.g. /text/json to /application/json)


2) relax SHOULD to MAY for Last-Modified when ETag is also supplied in the following sections:

2.2.1. Generation "An origin server SHOULD send Last-Modified for any selected representation for which a last modification date can be reasonably and consistently determined,"

2.4. When to Use… -- also says origin servers SHOULD send both ETag & Last-Modified; consider relaxing the SHOULD for Last-Modified or make the SHOULD contingent on absence of ETag.

Given that headers aren't currently compressed, unnecessary headers can lead to unexpected impact on payload sizes. Given that Last-Modified is redundant with weak ETags and inferior to strong ETags, when an ETag is supplied by the origin-server, origin-servers should be allowed the discretion of MAY provide Last-Modified instead of SHOULD.

Subpoint 2 in "2.4. A client" supports the "SHOULD only respond with Last-Modified if no ETag is available" point of view ("SHOULD send the Last-Modified value in non-subrange cache validation requests (using If-Modified-Since) if only a Last-Modified value has been provided by the origin server.")

  1. Precedence

Section six further supports this point of view. When both are sent by the user agent, Last-Modified is always ignored.

If the provision for sending both headers both directions all the time is to support HTTP/1.0 caches, be sure to state that as the reasoning in the relevant places.

believed to be answered in http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0533.html/


3) shared weak ETags

2.3.3. Note An encoded representation and an un-encoded representation can share a weak entity tag. Right?

Change History (8)

comment:1 Changed 6 years ago by julian.reschke@…

  • Severity changed from In WG Last Call to In IETF LC

comment:2 Changed 6 years ago by julian.reschke@…

  • Description modified (diff)

comment:3 Changed 6 years ago by julian.reschke@…

  • Description modified (diff)

comment:4 Changed 6 years ago by fielding@…

From [2473]:

remove sentence on strong validators being unique across representations because they are only required to be unique per representation data; addresses #518

comment:5 Changed 6 years ago by fielding@…

From [2474]:

clarify what should have been obvious from the next sentence, but improves readability; addresses #518

comment:6 Changed 6 years ago by fielding@…

2.1. Weak versus Strong -- "A strong validator might change for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g., Content-Type), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored responses held by remote caches"

It might benefit from clarification and an example:

clarification - "for other reasons" to "for reasons other than changes to the body"

Done in [2474].

example of a change to Content-Type that wouldn't result in change to the body (e.g. /text/json to /application/json)

No, just mentioning that Content-Type is an example is sufficient and already present.

2) relax SHOULD to MAY for Last-Modified when ETag is also supplied in the following sections:

Last-Modified is useful for more than caching. That is actually user-meaningful data, unlike ETag. It should be sent because not all caches support entity-tag based conditionals.

3) shared weak ETags

2.3.3. Note An encoded representation and an un-encoded representation can share a weak entity tag. Right?

Yes, will change to strong entity-tag.

comment:7 Changed 6 years ago by fielding@…

From [2475]:

clarify that content coding example is about strong entity tags; addresses #518

comment:8 Changed 6 years ago by fielding@…

  • Milestone changed from unassigned to 25
  • Resolution set to incorporated
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.