Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide an API for validating URI Templates #33

Open
Julian opened this issue Jun 17, 2017 · 9 comments · May be fixed by #36
Open

Provide an API for validating URI Templates #33

Julian opened this issue Jun 17, 2017 · 9 comments · May be fixed by #36

Comments

@Julian
Copy link

Julian commented Jun 17, 2017

Hi!

Would you consider an API to validate whether a particular input was valid under RFC 6570 (or does such a thing exist already and I've missed it)?

E.g., http://example.com/dictionary/{term:1}/{term is not a valid URI Template seemingly, but I cannot see an API that complains about that -- uritemplate.URITemplate will happily truncate the end part there and consider that a template with just one field.

(Even having URITemplate do enough validation of its inputs would also work).

Full context: JSON Schema Draft 6 adds a uri-template format. I'd love to use uritemplate to implement it in jsonschema.

@sigmavirus24
Copy link
Collaborator

Hi @Julian! Sorry for the delay. I love jsonschema and would love to be able to provide something useful for it. I don't think there's anything in RFC 6570 for validating a URI Template, but if we can come up with some ideas for a first pass at validation, I'd be happy to keep up with reasonable requests for expansion. That said, I may opt for functionality like what exists in rfc3986 for validation. There, we build a Validator object, tell it what we want it to validate and then pass in a URIReference object. I'm thinking we'd do the same here. Thoughts?

@sigmavirus24
Copy link
Collaborator

Also, could you expand on

E.g., http://example.com/dictionary/{term:1}/{term is not a valid URI Template seemingly, but I cannot see an API that complains about that -- uritemplate.URITemplate will happily truncate the end part there and consider that a template with just one field.

Here's my own experimentation with this:

>>> uritemplate.URITemplate('http://example.com/dictionary/{term:1}/{term')
URITemplate("http://example.com/dictionary/{term:1}/{term")
>>> u = _
>>> u.variables
[URIVariable(term:1)]
>>> u.expand(term=['foo', 'bar', 'bogus'])
'http://example.com/dictionary/foo,bar,bogus/{term'

{term is a valid portion of a URL. I don't know if we'd really want to mark that as an invalid Template. It's entirely possible that {term is an actual part of the URL. =/

@Julian
Copy link
Author

Julian commented Jun 25, 2017

Hullo! No worries.

Interesting, sorry, not sure how I made that mistake (about truncation). Does look like you're right certainly :).

So I am certainly no expert on RFC 6570 -- I did skim it just now and it does seem like from that 2 minute skim that it seems to be saying things like "when you're trying to expand stuff, if you can't, you return the thing unchanged, and then there's no guarantee that what you get back is a valid URI reference".

So I'm getting a sense that what a "valid" URI template might mean is one that when you expand it ends up expanding into an invalid URI reference according to RFC 3986? In which case maybe I wouldn't actually need any additional APIs, the algorithm would be "find all the terms, expand those with some values, then validate the result as a valid URI reference"?

But yeah I think there's some lack of clarity here (probably on the part of the JSON Schema spec?) on what exactly we mean by "valid URI template" (the example I shared was straight out of our own test suite). @handrews @epoberezkin have I totally missed something here?

That said, I may opt for functionality like what exists in rfc3986 for validation. There, we build a Validator object, tell it what we want it to validate and then pass in a URIReference object. I'm thinking we'd do the same here. Thoughts?

This sounds totally reasonable by the way.

@epoberezkin
Copy link

So I'm getting a sense that what a "valid" URI template might mean is one that when you expand it ends up expanding into an invalid URI reference according to RFC 3986?

@Julian My reading of the spec was that it is not required at all that URI template expands into a valid URI, there are many places in 6570 that at least imply it. It explicitly says that not all expansions would be valid URIs and also that the character set is wider.

I ended up just constructing a regular expression that [I think] matches ABNF from the spec, feel free to review and use it if you like: https://github.com/epoberezkin/ajv/blob/master/lib/compile/formats.js#L12

@epoberezkin
Copy link

epoberezkin commented Jun 25, 2017

@sigmavirus24 RFC 6570 prohibits curly braces in literals, they only can surround expressions, so the above is not a valid URI template according to their ABNF (also doesn't match my regular expression). See https://tools.ietf.org/html/rfc6570#section-2.1

@sigmavirus24
Copy link
Collaborator

@epoberezkin you're right. I haven't read the spec in a while and I just noticed

                        ; any Unicode character except: CTL, SP,
                        ;  DQUOTE, "'", "%" (aside from pct-encoded),
                        ;  "<", ">", "\", "^", "`", "{", "|", "}"

I'll have to correct for that.

@sigmavirus24
Copy link
Collaborator

So this is started in #36. I had trouble coming up with validations outside of the unbalanced braces because those "invalid characters" could be converted into their percent-encoded representations per the paragraph above that ABNF.

@sigmavirus24
Copy link
Collaborator

@Julian, this is a friendly ping for your feedback on #36.

@Julian
Copy link
Author

Julian commented Jul 31, 2017

Hey! Sorry, I was traveling a bit the past few weeks :), will have a look right now, thanks for getting to it!

Julian added a commit to python-jsonschema/jsonschema that referenced this issue May 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants