search

httpwg / httpbis-issues

1 stars 1 forks source link

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

Closed mnot closed 3 years ago

mnot commented 10 years ago

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?

Reported by julian.reschke@gmx.de, migrated from https://trac.ietf.org/trac/httpbis/ticket/518

mnot commented 10 years ago

julian.reschke@gmx.de changed severity from In WG Last Call to In IETF LC

mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

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.

3) shared weak ETags

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

to:

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.

3) shared weak ETags

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

mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

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.

3) shared weak ETags

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

to:

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?

mnot commented 10 years ago

fielding@gbiv.com commented:

From 2473:

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

mnot commented 10 years ago

fielding@gbiv.com commented:

From 2474:

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

mnot commented 10 years ago

fielding@gbiv.com commented:

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.

mnot commented 10 years ago

fielding@gbiv.com commented:

From 2475:

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

mnot commented 10 years ago