Review of draft-ietf-httpbis-p4-conditional-19.txt

Hi,
Sorry for being a bit late with this review.

> 3.2. If-None-Match
>
> If the request would, without the If-None-Match header field, result
> in anything other than a 2xx or 304 status code, then the If-None-
Should this list also include 412 listed above in the same section?
> Match header field MUST be ignored. (See Section 2.4 for a
> discussion of server behavior when both If-Modified-Since and If-
> None-Match appear in the same request.)

> 3.3. If-Modified-Since
>
> The "If-Modified-Since" header field MAY be used to make a request
> method conditional by modification date: if the selected
> representation has not been modified since the time specified in this
> field, then do not perform the request method; instead, respond as
> detailed below.

This section doesn't seem to say anything about methods other than GET,
yet the text seems to imply that a more general case is also covered 
"below",
yet this section only talks about GET.

> 3.4. If-Unmodified-Since
>
> If the specified date is invalid, the header field MUST be ignored.

Here and elsewhere in the document: do you mean syntactic validity,
semantic validity (e.g. date in the future are invalid) or both?

> 4.1. 304 Not Modified
>
> If the recipient of a 304 response does not have a cached
> representation corresponding to the entity-tag indicated by the 304
> response, then the recipient MUST NOT use the 304 to update its own
> cache. If this conditional request originated with an outbound
> client, such as a user agent with its own cache sending a conditional
> GET to a shared proxy, then the 304 response MAY be forwarded to the
> outbound client.
This looks strange: an outbound client ... MAY forward the 304 response to
the outbound client?

Received on Monday, 16 April 2012 15:07:20 UTC