Re: [OT] HTTP etag vs if-* vs range vs content-encoding?

[Sam Roberts <sroberts@...>]

On Thu, Feb 01, 2007 at 09:10:07PM +0100, PA wrote:
> >You have read RFC2616, right?
> 
> Yes... but I'm still not 100% clear about somewhat basic things like do 

This is from memory, but...

> you gzip a response first and then compute it's etag or the other way 
> around...

ETAG isn't computed, its assigned by you to a specific version of a
resource.  Its only requirement is to be different if the resource is
different.  It doesn't vary with the transfer encoding. If you choose to
do it with digests, which is what it sounds like, digest before gzip.

> content or not... how does a conditional requests fits with a range 
> request, etc...

Don't conditional requests apply to a resource? If the condition is met,
then you get the range you asked for.

> At a more practically level, I have a small set of filters 
> (ConnectionFilter, GZIPFilter, ETagFilter, ConditionalFilter, 
> RangeFilter, MD5Filter, LogFilter) and  I would like to make sure they 
> are ordered properly :)

You can do it any way you want, as long as the result is as specified in
the RFC, but HTTP doesn't have a pipeline model, its not described in
this way, as a series of transformations. You will have to read pretty
carefully to make sure the results are correct, and the answers to your
questions are in the RFC.

See 14.15 Content-MD5, for example, it says MD5 is applied to an entity
body after content-coding, but before transfer-encoding, so it goes
after the range, after gzip, but before transfer encoding (which I don't
see in your filter names, maybe you always use identity encoding).

Also, I don't have time to look all this stuff up in the RFC, but I very
much doubt that range selection occurs after gzip. If it did, asking for
range 100-200 would get DIFFERENT data, potentially, every time you
asked!  gzip doesn't guarantee that every time it runs you get binary
identical output.

Btw, I'd suggest NOT implementing in the server anything a client isn't
going to use. It saves work. Also, if you take this approach, everything
you implemented is used by a client, so you can test your server by
checking interop with real clients. Maybe you need all those features,
maybe you don't, thats your call, depends on your application, but
features you implement that you don't test to show they interop with 3rd
party code are pretty unlikely to be implemented correctly.

Cheers,
Sam