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

I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-httpbis-p4-conditional-24
Title: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
Reviewer: Ray Polk
Review Date: November 3, 2013


Major Issues: None

Minor Issues:

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.")

6. 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?


Nits: None

Received on Monday, 4 November 2013 06:45:49 UTC