Re: ETag specification: load balance friendly and merge with Digest header from

[Roberto Polli <[e-mail]>]

Hi Sergey,

Digest header was introduced long ago via Rfc3230. We are just updating
it...

It's goal is different from etag though, but you can use digest-algorithms
to compute strong etags. Consider though that digest changes when
localising resources (eg. Via content-language) while weak etags probably
won't.

If someone thinks we should describe the relationship between digest and
etags in the new spec we can do it.

Have a nice day,
R

Il lun 13 lug 2020, 02:28 Sergey Ponomarev <[e-mail]> ha scritto:

> Hi,
>
> I just implemented ETag caching for BusyBox httpd which is a http server
> for embedded devices like WiFi routers.
> While implementing I had to choose what exactly should be generated as
> ETag.
> ETag is specified in https://tools.ietf.org/html/rfc2616#section-14.19 as
> an opaque value and a server is free to generate it as it needs.
> In the https://httpwg.org/specs/rfc7232.html#rfc.section.2.3 Conditional
> Requests are better explained strategies to generate and compare ETags.
> But even in the upcoming HTTP Caching draft-ietf-httpbis-cache-09 no any
> practical details about ETag generation.
>
> I did small research and found out that all web servers do it in their own
> way and this causes several problems:
> 1. ETag may be badly or even wrongly generated.
> 2. When two different servers e.g. Apache and Nginx are behind load
> balancer then their ETags will be always discarded because they are
> generated differently. That's why some sysadmins disable ETag on one of the
> servers.
> These problems can be easily fixed if HTTP specification will provide a
> recommended way to generate ETags while keeping freedom of choice.
>
> Typical ETag is based on file's Last Modification Time and Size which can
> be easily retrieved from the file system but can be a more strict hash or
> checksum and sometimes a semantic version.
>
> Just a quick overview of typical algorithms used in webservers.
> Consider  we have a file with
> * Size 1047 i.e. 417 in hex.
> * MTime i.e. last modification on Mon, 06 Jan 2020 12:54:56 GMT which
> is 1578315296 milliseconds in unix time or 1578315296666771000 nanoseconds.
> * Inode which is a physical file number 66 i.e. 42 in hex
>
> Different webservers returns ETag like:
> Nginx: "5e132e20-417"                         i.e.
> "hex(MTime)-hex(Size)". Not configurable.
> Apache/2.2: "42-417-59b782a99f493"  i.e.  "hex(INode)-hex(Size)-hex(MTime
> in nanoseconds)". Can be configured but MTime anyway will be in nanos
> http://httpd.apache.org/docs/2.4/mod/core.html#fileetag
> Apache/2.4: "417-59b782a99f493"       i.e.  "hex(Size)-hex(MTime in
> nanoseconds)" i.e. without INode which is friendly for load balancing when
> identical file have different INode on different servers.
> OpenWrt uhttpd: "42-417-5e132e20"    i.e.
> "hex(INode)-hex(Size)-hex(MTime)". Not configurable.
> Tomcat 9: W/"1047-1578315296666"   i.e.  Weak"Size-MTime in Nanoseconds".
> This is incorrect ETag because it should be strong as for a static file
> i.e. octal compatibility.
> LightHTTPD:  most weird:  "hashcode(42-1047-1578315296666771000)" i.e.
> INode-Size-MTime but then reduced to a simple integer by hashcode. Can be
> configured but you can only disable one part (etag.use-inode = "disabled")
>
> Hex numbers are used here so often because it's cheap to convert a decimal
> number to a shorter hex string.
> Inode while adding more guarantees makes load balancing not possible and
> very fragile if you simply copied the file during application redeploy.
> MTime in nanoseconds is not available on all platforms and we don't need
> such granularity. Apache have reported bugs on this like
> https://bz.apache.org/bugzilla/show_bug.cgi?id=55573
> The order MTime-Size or Size-MTime  is also matters because MTime is more
> likely changed so comparing ETag string may be faster for a dozen
> CPU cycles.
> Even if this is not a full checksum hash but definitely not a weak ETag.
> This is enough to show that we expect octal compatibility for Range
> requests.
> Apache and Nginx shares almost all trafik in Internet but most static
> files are shared via Nginx and it is not configurable.
>
> If I am not missing anything then it looks like Nginx uses the most
> reasonable schema. And I used it for BusyBox httpd.
> The whole ETag generated by printf("\"%" PRIx64 "-%" PRIx64 "\"",
> last_mod, file_size)
>
> My proposition is to take Nginx schema and make it as a recommended
> ETag algorithm. Or at least just to mention in rfc7232 as an example.
> And other servers should have at least possibility to configure such ETag
> form.
> I'll try to engage other web servers teams into the discussion and 'll try
> to create patches for them.
>
> While having the simple MTime-Size ETag algorithm solves a bunch of
> problems but some systems wants to have more guarantees and they need hash
> based ETags.
> Any hash even MD5 or CRC32 is great to use as ETag.
>
> There is a draft of Digest Headers
> https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-digest-headers.md .
> It's idea is similar to Subresource Integration (SRI).
> And in fact instead of introducing the new Digest header we can just reuse
> ETag header with prefix.
>
> Respectively instead of:
>
>     Digest: sha-256=4REjxQ4yrqUVicfSKYNO/cF9zNj5ANbzgDZt3/h3Qxo=
>
> We can use
>
>     ETag: "sha-256=4REjxQ4yrqUVicfSKYNO/cF9zNj5ANbzgDZt3/h3Qxo="
>
> Client can easily parse ETag header and by prefix determine the way to
> validate.
> We'll have "structured ETag" and they are already supported by proxies.
>
> For the same file server can send two comma separated ETags: one MTimeSize
> and additional digest based. Old clients just resend them via
> If-None-Match. If a server like BusyBox can only validate MTimeSize Etag it
> will validate it and ignore sha256 based ETag.
>
> BTW the file hashes can be stored ext4 in extended attributes to avoid
> recalculating.
>
> Please tell your thoughts and opinions and share best practice for ETags.
>
> See also:
> Apache code to generate ETag
> https://searchcode.com/codesearch/view/28934406/
> LightHTTPD
> https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/master/src/etag.c
>
> --
> Sergey Ponomarev <https://linkedin.com/in/stokito>, skype:stokito
>
>
>