Check length: before in: and format:

[VSN2015]

Same question as #24, different bound: does the cheap check run before the expensive one?

The problem

length: is an O(1) read of a String's size. format: runs a regexp over the whole value; validate: runs arbitrary app code. Checking the cheap bound last meant a value the bound already excluded still paid for the expensive ones.

A 5 MB string against an entirely ordinary declaration:

required :email, :string, length: 1..80, format: URI::MailTo::EMAIL_REGEXP

	Time
Before	121 ms — the regexp scanned all 5 MB (82 ms of it), and the result was then thrown away by the length check
After	38 ms — the regexp is never consulted (the residual is HashWithIndifferentAccess conversion of the payload)

With a well-behaved regexp that is waste. With an app regexp that has poor worst-case behaviour it is a lever, available to anyone who can send a long string to a bounded field — which is every field that declares a length at all.

The fix

normalize:  →  cast  →  length:  →  in:  →  format:  →  validate:

First failure reported, and the order is now documented in the README.

The one observable change

A value violating both its length and its format reports length instead of format/inclusion. That's the more useful answer anyway — a client can't act on "wrong format" for a value that is also far too long.

Nothing else moves: a field with no length: checks format: exactly as before, and a value inside its length bound still gets the full set of checks in order.

How the spec proves it

Asserting the reported code would only show format was outranked, not that it was skipped. So the spec passes a Regexp subclass that records whether match? was called — satisfying any format: type check while staying observable:

expect(e.details).to eq([{ param: "s", code: "length" }])
expect(spy.consulted?).to be(false)

and the companion spec asserts it is consulted for a value within the bound.

Verification

• 203 examples, 0 failures (4 new, written before the change)
• RuboCop clean

[VSN2015]

Review of PR #25: Sensible check ordering optimization. Running O(1) string length checks prior to regex format evaluation and custom validation callbacks prevents ReDoS and wasted processing on oversized strings.

[VSN2015]

Checking length: before in: and format: protects regex matching from having to evaluate giant string inputs when the length bound has already failed.

[VSN2015]

Using a spy_format subclass of Regexp to verify that match? is never invoked on length-violating inputs is a great test design.