servers should support hearing "not new descriptor"
Directory authorities, when they get a descriptor that isn't new enough (more than cosmetically different) right now send back a 200 response code.
We should send some different code, so servers have a chance of knowing whether their uploaded descriptor actually "took" or was silently discarded.
So, changes as I understand them: A) Tor servers should accept 200-299 as successes, not just 200.
B) What success code, within the range 201-299, most closely resembles "I accepted it but it wasn't new enough so I didn't use it"? Is there any precedent to follow here?
C) Once step A is done, authorities can start sending back other codes.
D) Is there any way to speed up reaching step C?
E) Should we also change 400 to a range 400-499?
[Automatically added by flyspray2trac: Operating System: All]
Activity
changed milestone to %Tor: unspecified in legacy/trac
Ok. B, C, and D should be solved by Nick's suggestion of using a new http header to describe what variation on 200 we meant.
A and E remain as separate questions. Any reason not to make clients flexible enough to know what class of response was sent, in case down the road we find another situation where an already-defined RFC response code matches what we mean to say? The behavior I would imagine is to treat 201-299 the same as 200 (silently be happy), and to treat unrecognized 4xx's as the same as 400 (log to the user that "we just got a 4xx; please correct").
Marking for 0.2.3.x-final.
Trac:
Description: Directory authorities, when they get a descriptor that isn't new enough (more than cosmetically different) right now send back a 200 response code.We should send some different code, so servers have a chance of knowing whether their uploaded descriptor actually "took" or was silently discarded.
So, changes as I understand them: A) Tor servers should accept 200-299 as successes, not just 200.
B) What success code, within the range 201-299, most closely resembles "I accepted it but it wasn't new enough so I didn't use it"? Is there any precedent to follow here?
C) Once step A is done, authorities can start sending back other codes.
D) Is there any way to speed up reaching step C?
E) Should we also change 400 to a range 400-499?
[Automatically added by flyspray2trac: Operating System: All]
to
Directory authorities, when they get a descriptor that isn't new enough (more than cosmetically different) right now send back a 200 response code.
We should send some different code, so servers have a chance of knowing whether their uploaded descriptor actually "took" or was silently discarded.
So, changes as I understand them: A) Tor servers should accept 200-299 as successes, not just 200.
B) What success code, within the range 201-299, most closely resembles "I accepted it but it wasn't new enough so I didn't use it"? Is there any precedent to follow here?
C) Once step A is done, authorities can start sending back other codes.
D) Is there any way to speed up reaching step C?
E) Should we also change 400 to a range 400-499?
[Automatically added by flyspray2trac: Operating System: All]
Parent: N/A to N/A
Keywords: N/A deleted, N/A added
Milestone: post 0.2.1.x to Tor: 0.2.3.x-finalThis is the only way to fix legacy/trac#3327 (moved) (and legacy/trac#1810 (moved)).
I suggest that we add an ‘on-response’ callback parameter to every function that launches a directory request, and use that callback to update a ‘last descriptor upload time’ global variable iff the new descriptor was accepted.
Trac:
Type: enhancement to defect
Points: N/A to N/A
Milestone: Tor: 0.2.3.x-final to Tor: 0.2.2.x-final
Parent: N/A to legacy/trac#3327 (moved)
Priority: minor to critical
Actualpoints: N/A to N/A-
If we want this in 0.2.2.x, the changes need to be MUCH MUCH smaller than adding new callbacks, changing interfaces, etc. We already have the code in connection_dir_reached_eof that gets called on every response from the dirserver. I'd like to change the architecture, but not for 0.2.2.
So, what's the correct actual behavior here?
We want to remember, for each authority, the 'published' time of the last descriptor that it accepted from us. We want to have another global in router.c, something like "desc_clean_since", that remembers the last time that we had our descriptor accepted by sufficient authorities. We can then replace "mark_my_descriptor_dirty_of_older_than" with a new function that declares the descriptor to be dirty if it is too old, OR if too much time has passed since sufficient authorities accepted one of our descriptors.
Or another option is to look at the publication time for the version of our descriptor that's listed in the directory consensus. This could probably use some pseudocode. Also, it feels like something to do as a branch that gets merged first to 0.2.3.x for testing, then back to 0.2.2.x: none of the solutions here feel as obvious and straightforwardly harmless as I'd want.
Trac:
Priority: critical to major -
I uploaded a fix for legacy/trac#3327 (moved) that should make a fix here unnecessary; please review the branch mentioned in that ticket.
-
Can we close this now that legacy/trac#3327 (moved) is merged? Instead of hearing "not new", servers now upload more frequently when they do not appear in a consensus, or when the version of their descriptor listed in the consensus is very old.
-
Trac:
Parent: legacy/trac#3327 (moved) to N/A mentioned in issue legacy/trac#3327 (moved)
moved from legacy/trac#535 (moved)
added Bug label and removed 1 deleted label