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

NEW
Unassigned

Status

()

defect
P3
normal
6 years ago
2 years ago

People

(Reporter: jduell.mcbugs, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-backlog])

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.
Summary: Add fields to index to determine if revalidation needed w/o doing I/O → Add fields to HTTP cache index to determine if revalidation needed w/o doing I/O
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.
Whiteboard: [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.