[metrics-bugs] #21934 [Metrics/metrics-lib]: Allow extra arguments in lines containing comma-separated key-value lists
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Apr 26 14:35:45 UTC 2017
#21934: Allow extra arguments in lines containing comma-separated key-value lists
---------------------------------+------------------------------
Reporter: karsten | Owner: metrics-team
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Metrics/metrics-lib | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
---------------------------------+------------------------------
Comment (by iwakeh):
[https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n923 dir-
spec] defines the field `dirreq-v3-resp` more narrowly (the 'nul' there
should be 'num'):
{{{
"dirreq-v3-resp" status=nul,... NL
[At most once.]
}}}
Which I would take to mean only status-types are allowed on the left of
equal and a number to the right, but of these an arbitrary number. But,
response statuses can be added any time, so the patch above seems to do
the right thing. The further parsing doesn't verify the status strings,
which is correct for 'dirreq-v3-resp'.
There seems to be an ambiguity in defining these things, for
[https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1058
example]:
{{{
"cell-circuits-per-decile" num NL
[At most once.]
}}}
In this case only a single value makes sense, but other than not using the
dots it is not expressed clearly in dir-spec. Could a value be added
(e.g. the median) here without changing the protocol?
In order to check for all fields it might be necessary to go through all
fields one by one and check.
What comes to mind is using a grammar for checking the spec definitions.
Were there reasons once upon a time not to use a grammar and automated
checking for the spec?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21934#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the metrics-bugs
mailing list