Opened 5 years ago

Closed 5 years ago

#13963 closed defect (fixed)

If Modified Since delay is too long when V3AuthVotingInterval is very short

Reported by: teor Owned by: teor
Priority: Medium Milestone: Tor: 0.2.6.x-final
Component: Core Tor/Tor Version: Tor: 0.2.6.1-alpha
Severity: Keywords: tor-auth tor-dir tor-client
Cc: nickm Actual Points:
Parent ID: #13718 Points:
Reviewer: Sponsor:

Description

Clients add 3 minutes to the last consensus valid after time to create an "If Modified Since" header. This works when MIN_VOTE_INTERVAL is 5 minutes.

But when the V3AuthVotingInterval is set lower in a testing network (see #13823 and #13718), 3 minutes can be far too long to wait for an updated consensus. (For example, MIN_VOTE_INTERVAL_TESTING is 10 seconds.)

I'd like to set the "If Modified Since" header to halfway between the valid after and fresh until times, but only when the V3AuthVotingInterval is particularly short (less than 6 minutes).

By comparison, the default of 3 minutes is 1/20 the default consensus interval of 60 minutes.

Child Tickets

Change History (5)

comment:1 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-final

comment:2 Changed 5 years ago by teor

This fix means we don't have to do anything special for consensus downloads for #13976 to work as expected.

comment:3 Changed 5 years ago by teor

Owner: set to teor
Status: newassigned

comment:4 Changed 5 years ago by teor

Status: assignedneeds_review

The changes to tor in #13718 have fixed this:

Bugs: #13718, #13814, maybe #13787, #13839, #13924, #13823, #13929, #13963
Branch: bug13718-fast-bootstrap
Note: There are 5 branches that start with bug13718, please choose the right one.
Repository: ​​​​​​​​https://github.com/teor2345/tor.git

comment:5 Changed 5 years ago by teor

Resolution: fixed
Status: needs_reviewclosed

Committed as part of bug13718-consensus-interval merge

Note: See TracTickets for help on using tickets.