Subject: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p4-conditional-24

From: Ray Polk <[email-masked]>
Date: Sun, 3 Nov 2013 22:45:00 -0800 (PST)

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 05 Nov 2013 00:28:53 +0100

On 2013-11-04 07:45, Ray Polk wrote:
> ...
 > ...

...and it continues with...

"...since its use in conditional requests and evaluating cache freshness 
([Part6]) results in a substantial reduction of HTTP traffic on the 
Internet and can be a significant factor in improving service 
scalability and reliability..."

I believe that's the reason why it is a SHOULD.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 4 Nov 2013 15:39:57 -0800

On 4 Nov 2013, at 3:28 pm, Julian Reschke <[email-masked]> wrote:

> "...since its use in conditional requests and evaluating cache freshness ([Part6]) results in a substantial reduction of HTTP traffic on the Internet and can be a significant factor in improving service scalability and reliability..."
> 

Yes. This was discussed extensively; it was felt that the benefit to the network was significant enough to include a “social SHOULD.”

Cheers,

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