BIND 10 #917: update stats-httpd to return only specified statistics
BIND 10 Development
do-not-reply at isc.org
Tue Nov 8 09:24:31 UTC 2011
#917: update stats-httpd to return only specified statistics
-------------------------------------+-------------------------------------
Reporter: | Owner: naokikambe
naokikambe | Status: reviewing
Type: | Milestone:
enhancement | Sprint-20111108
Priority: major | Resolution:
Component: | Sensitive: 0
statistics | Sub-Project: DNS
Keywords: | Estimated Difficulty: 6
Defect Severity: N/A | Total Hours: 0
Feature Depending on Ticket: |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by vorner):
* owner: vorner => naokikambe
Comment:
Hello
I can confirm the statistics are shown now.
Replying to [comment:12 naokikambe]:
> Replying to [comment:10 vorner]:
> > * In this code, it looks unclean to decide by the text of exception:
> > {{{#!python
> > # Couldn't find neither specified module name nor
> > # specified item name
> > if str(err).startswith('Stats module: specified arguments are
incorrect:'):
> > self.send_error(404)
> > else:
> > self.send_error(500)
> > }}}
> > Would it be possible to throw inherited exception in that case?
>
> I added a new exception !StatsHttpdDataError. It is raised when an
> error due to the specified data is occurred. If it's raised,
> stats-httpd will return 404 notfound. Please see git
df02b63fe1176c572a7eee996921f211ca970953.
This introduces one new problem: the `STATHTTPD_SERVER_ERROR` log message
is used twice, which shouldn't happen. Could you create a new one for the
404 error?
> > * Is it really OK to do this? Can't the conversion to us-ascii lose
some characters? Can't there be non-ascii characters in the XML?
> > {{{
> > xml_string = str(xml.etree.ElementTree.tostring(xml_elem,
encoding='utf-8'),
> > encoding='us-ascii')
> > }}}
>
> Yes, it loses non-ascii characters. That was added in #1021 but that
> might be a work around. However I think that such non-ascii characters
> wouldn't be acceptable in the system. If we make that acceptable, we
> have to totally review the specification of the whole system. I know
> such non-ascii characters are urgent into the future, but do we need
> it now?
I guess it's not needed now. It just looked suspicious, so I pointed it
out. If there are no non-ascii characters expected for now, it should
work.
> > * The recursive closures detect where they are in the structure by
the type of parameter. Wouldn't it be better to write a separate function
for each of the cases? Because we should be sure what type there is when
we call it recursively.
>
> Such internal functions are temporary in this ticket. I'd like to
> this task would be bigger. Sorry, please give me any suggestions if
> you have.
It's probably OK if they are temporary.
Thank you
--
Ticket URL: <http://bind10.isc.org/ticket/917#comment:14>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list