On Wed, 4 Jun 2003, chris_pressey wrote:

> 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

Except for
If-Match: *

> - any request with only If-None-Match will never return 412

Except for
If-None-Match: *
especially for non-GET/HEAD methods.

> ...since a client which sends my server any entity tags is obviously
> confused (since it couldn't have got them from my server! :)

In general, your server may be serving content that was previously
served by an ETag-generating server, explaining now-stale e-tags in
request headers; so the client is not necessarily "confused". The "*"
case is used to make PUTs and such safer.

Also be careful with If-Range if you are going to support ranges,
because If-Range can use HTTP-date as a validator (section 14.27) so
you cannot ignore it even if you generate no entity-tags.

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

The logic behind all If-* headers is not that complex after you digest
RFC wording into something more systematic/algorithmic (which may take
days). The core of it can be expressed in less than 100 lines of code.
Nevertheless, if you can bypass all e-tag operations, your code will
be simpler, of course.

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

Generating ETags is optional.

Alex.

--
| HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
| all of the above - PolyBox appliance