bibxml-service

bibxml-service copied to clipboard

Sentry Issue: BIBXML-SERVICE-M

ValueError: Invalid Datatracker ID: moss-named-ports-v.01
(7 additional frame(s) were not displayed)
...
  File "django/views/decorators/cache.py", line 56, in _wrapped_view_func
    response = view_func(request, *args, **kwargs)
  File "django/views/decorators/http.py", line 40, in inner
    return func(request, *args, **kwargs)
  File "xml2rfc_compat/views.py", line 211, in handle_xml2rfc_path
    adapter = adapter_cls(xml2rfc_subpath, normalized_dirname, anchor)
  File "bibxml/xml2rfc_adapters.py", line 155, in __init__
    unversioned, version = remove_version(self.bare_anchor)
  File "datatracker/internet_drafts.py", line 51, in remove_version
    raise ValueError("Invalid Datatracker ID: %s" % id)

The ID is definitely invalid, it is likely to should have been moss-named-ports-01. @strogonoff what should we do with this?

Another URL that is causing above error: http://bib.ietf.org/public/rfc/bibxml-ids/reference.i-d.draft-harkins-pkex-02.xml

Sentry issue: BIBXML-SERVICE-Y

This another unhandled error captured on Sentry, breaks at the same point: https://bib.ietf.org/get-one/export/?docid=draft-gont-tcpm-rfc1948bis%27%5B0%5D&doctype=Internet-Draft&format=relaton

Another URL that is causing above error: http://bib.ietf.org/public/rfc/bibxml-ids/reference.i-d.draft-harkins-pkex-02.xml

This URL contains i-d in lowercase, the logic assumes I-D. This could be changed, of course🤔

The ID is definitely invalid, it is likely to should have been moss-named-ports-01. @strogonoff what should we do with this?

It looks like the path was not given correctly. We could find out where this request came from, but generally this implementation follows a request not to try to interpret paths with fuzzy matching (which was the case with my initial implementation). There is a comment somewhere that requests xml2rfc paths for I-Ds to fail if a path does not match the expected structure, even if we can extract enough useful information from it, and not failing is to be treated as a bug.

• However, that this path fails with 500 may be a regression. I suspect there should be an error handler that catches this and returns HTTP 404.
• The path pasted by Kesara, depending on where it came from, may indicate a necessity of supporting lowercase i-d. prefix in addition to uppercase one—if that’s API users’ expectation—which would call for a corresponding change.

As @strogonoff mentioned, during implementation @rjsparks has advised that any paths not matching the expected path pattern should return an error.

@rjsparks has this decision changed since, that fuzzy path matching is to be implemented?

no - that has not changed, and .i-d. is not intended to work.