Go-swagger: Validator: should accept JavaScript regexps (but warn?)

[dolmen]

Problem statement

This regexp is valid in JavaScript and (so as a pattern schema constraint in Swagger) but rejected by swagger validate:
^[a-z](?=.{0,20}$)(?:[a-z0-9_]{0,4}:[a-z0-9_])?[a-z0-9_]{0,20}$

In this regexp the assertion enforces that the whole string is always at most 21 characters long.

This cause of this failure is probably that the Go regexp package recognizes a smaller regexp syntax subset than Perl and JavaScript: it doesn't recognizes (?= ... ) (zero-width positive look-ahead assertion).

Swagger specification

Steps to reproduce

Use the regexp in a pattern in a schema definition for a type string.

Environment

swagger version: 248eca73c69f2d5f0dbc94d49299e028c675960e
go version: 1.7.5

[GlenDC]

Sadly this is not supported in Golang's regexp (std) package, as there hasn't been found an efficient way of implementing features such as lookahead, while keeping their O(n) complexity guarantee.

Relevant discussion: https://github.com/golang/go/issues/18868

So there is not much we can do I'm afraid, for the time being you'll have to refactor your Regexp in a way that you're not relying on the lookahead feature.

[casualjim]

related to OAI/OpenAPI-Specification#880

even otto.js punted on implementing the javascript regex. So the only option that is left to support this is to link with a C-based library. I don't want to do that because it kills portability.

Should there be a pure go implementation of ECMA-262 regular expressions appear, I wouldn't mind integrating it

More info:

• https://github.com/robertkrimen/otto#regular-expression-incompatibility
• robertkrimen/otto#132
• robertkrimen/otto#215

[casualjim]

Look into integrating: https://github.com/dlclark/regexp2

[dolmen]

@GlenDC Refactoring of this particular pattern is possible (but the result is much less readable), but that may not be practical for all cases. And most importantly, that's not the point. A Swagger spec using this pattern is valid. So "swagger validate" has a bug. I understand that go-swagger may not be yet able to generate working client and server code from this regexp because of limitations of the regexp engine, but that's not the point: "swagger validate" should work anyway.

@casualjim The better solution would be to use the best of both worlds: use regexp if possible (because it safer against DoS attacks and is in stdlib) and use regexp2 only for patterns that use extended syntax (when regexp.Compile fails).