983122 - Add fields to HTTP cache index to determine if revalidation needed w/o doing I/O

Status: NEW

(Core :: Networking: Cache, defect, P3)

Description

[Jason Duell]

We can launch validation without I/O if we 

1) keep SHA1 hash of URI (bigger, but no collisions).  This is a space tradeoff vs using a smaller hash

2) store etag and last-modified info to index.

Comment 1

[Honza Bambas (:mayhemer)]

For the collision case:

say URL1=http://foo.bar/baz and URL2=https://abrakadabra.net/hoo have the same SHA1.

we have an entry for URL1 with an etag 'baz'.
we want to load URL2
we find 'baz' etag for it (collision)
we send it out as: GET /hoo Host: abrakadabra.net ETag: baz
here it branches:
1. baz is a valid etag for the abrakadabra.net content, we get a 304
2. baz is not valid etag, we get 200

For the case 1:
- the channel wants to load from the cache, but the entry is not found (we have hit a collision)
- nsHttpChannel is not designed right now for the case since it expects to have the cache entry in hands after a 304 response ; work's needed here

For the case 2:
- we create a new cache entry for URL2 (that will overwrite the file for URL1)
- channel will receive the new content, and be happy


Issue in case 1:

we leak etags to different origins, this could be used for user tracking at least: I want to know if user has ever visited say "https://mybankx.com/login" so I'll find a colliding URL1 on my evil server and watch for etag/ims request headers.  Hard work but doable.

Comment 2

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 3

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258