--- In http-compliance@yahoogroups.com, Alex Rousskov <rousskov@m...>
wrote:
> There is no clear/single MUST that says "the server MUST support a
> conditional or partial GET", I think. However, you may still get a
> practical answer to your questions. I would just recommend looking
at
> the problem from a different point of view:
>
> * Returning 412s for mismatched If-Match is a MUST (14.24).
> Thus, you cannot ignore If-Match.
>
> * Returning 304s for matching If-Modified-Since is a
> SHOULD (Section 14.25). Thus, you can ignore
> If-Modified-Since in this context.
>
> * Returning 200s/304s for matching If-None-Match is
> a MUST (14.26). Thus, you cannot ignore If-None-Match.
>
> * If-Range MUST be ignored if the server does not
> support the sub-range operation (14.27). Thus, you
> can ignore If-Range. (Same for Range, BTW).
>
> * Returning 412s for mismatching If-Unmodified-Since
> is a MUST (14.28). Thus, you cannot ignore
> If-Unmodified-Since.
>
> * Returning 304s for mismatching If-Modified-Since
> while other If-* headers match is a MUST NOT (13.3.4).
> Thus, you cannot ignore If-Modified-Since if other
> conditional headers are present. This rule probably
> excludes If-Range since there is a more specific
> MUST that says you can ignore it.
>
> At this point, we can conclude that you can ignore If-Range, but
must
> support/recognize/honor all other If-* headers if you want to be
> conditionally compliant in all cases. However, you can return 200 OK
> responses to matching If-Modified-Since requests as long as those
> requests do not contain other If-* headers.
>
> HTH,
>
> Alex.

Thanks for your reply.

Two of my primary design goals are conditional compliance and
simplicity, so I'd like to be able to reduce this problem to an
absolute, yet practical, minimum. This brings me to a followup
question.

I have not yet seen a clear MUST in regard to generating and sending
ETags. The closest I have seen are:

- "An entity tag MUST be unique across all versions of all entities
associated with a particular resource." (3.11)
- "Servers MUST NOT depend on clients being able to choose
deterministically between responses generated during the same second"
(13.2)

On the assumption that it is optional for an origin server to
generate ETags, would it also be acceptable to assume that:
- any request with only If-Match will always return 412
- any request with only If-None-Match will never return 412
...since a client which sends my server any entity tags is obviously
confused (since it couldn't have got them from my server! :)

If this is the case it would greatly simplify my server; I would
still have to add code to parse dates to satisfy If-Unmodified-Since
(and at that point I might as well implement If-Modified-Since too,
since it's a near-trivial variation on If-Unmodified-Since), but the
logic for handling If-[None-]Match would remain minimal.

On the other hand, if ETags are a MUST, I suppose I will have to
consider the simplest way to generate them, first.

Thanks again for your time.
-Chris