Incorrect test case in negative tests? "/vars/:var" , false

Question

Incorrect test case in negative tests? "/vars/:var" , false

Closed this issue 12 years ago · 8 comments

Hello everyone,

Is this test [ "/vars/:var" , false ] from negative tests correct? Could you please explain the reason? I'm doing some work related to URI templates and this one confused me.

Thanks in advance!

ioseb

Answer 1 · 2012-07-03T19:55:21.000Z

And this one is not clear for me too: [ "{keys:1}", false ]

Answer 2 · 2012-07-03T20:40:41.000Z

Hi

"/var/:var" is 100% correct. It was added because some people could mix up the syntax of a uri template with a double-dot based template. A uri template implementation could (should?) warn a user about this. Please feel free to come up with a better idea on how to express this. I'm not happy with the actual state.
"{keys:1}" is a valid template, but composite values ( aka. associative arrays/hashes/... ) may not have a length limit ( see: RFC6570 Section 2.4.1)

Cheers!
Hannes

Answer 3 · 2012-07-03T21:09:11.000Z

@hannes

Thank you very much!

A uri template implementation could (should?) warn a user about this. Please feel free to come up with a better idea on how to express this. I'm not happy with the actual state.

I'd rather ignore this case at all if template is 100% correct. As i understand spec doesn't define behavior what should happen in similar cases? in my implementation(https://github.com/ioseb/uri-template) it's possible to determine such specific case on parsing level and warn user, though it's not clear for me what shall i say? just define warn level and describe in documentation that warn level 13(for example) means that user is trying to use different template format?

"{keys:1}" is a valid template, but composite values ( aka. associative arrays/hashes/... ) may not have a length limit ( see: RFC6570 Section 2.4.1)

Thanks!! i missed this detail, it's 100% clear now.

P.S.
I already incorporated most of negative tests and extended examples alongside with all use cases which were defined in RFC. Tests repo is extremely helpful, thanks for doing this!

Best regards,
ioseb

Answer 4 · 2012-07-03T21:27:57.000Z

@ioseb :

I'm ignoring this case in my implementation either. There was some discussion how we can mark this really optional things. Maybe something like

["/:var", { 'warn' => 'looks like double dot syntax'} ]

would make this clear.

Answer 5 · 2012-07-03T21:39:53.000Z

@hannesg

at some point it makes sense, but looks like something very platform specific. there are a lot of routing libraries which adopt various kinds of template syntax and this approach may lead to extra overhead on implementation level which may not be necessary(in my opinion of course).

cheers!

Answer 6 · 2012-07-06T05:29:35.000Z

"/var/:var" is really testing to see if it's a valid uri, not a template.

I.e., if I pass the template

"/foo/bar", I'd expect to get "/foo/bar" as output (i.e., it has no templates).

The question is whether we expect URI template implementations to fail upon input that's a valid URI template, but doesn't produce a valid URI.

My feeling is that it's OK to have this kind of test, but it probably belongs in a separate file, so that people can opt into it.

Maybe "uri-tests.json"?

Answer 7 · 2012-07-06T18:03:56.000Z

Hi Mark

I would appreciate having some invalid URIs in "uri-tests.json"!

However, I think "/var/:var" actually is a valid URI path according to RFC 3986 3.3, isn't it?

Thank You
Hannes

Answer 8 · 2012-07-09T00:36:35.000Z

Ah, so it is; a member of pchar. Never mind. That test should just pass through the input string...