OAS 3 String format validation not working in path

[zekth]

Seems like the string format validation does not seem to work in path

paths:
  /uuid-pattern/{param}:
    get:
      parameters:
        - in: path
          name: param
          required: true
          schema:
            type: string
            pattern: '^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$'
            minLength: 36
            maxLength: 36
      responses:
        '200':
          description: success
  /uuid-format/{param}:
    get:
      parameters:
        - in: path
          name: param
          required: true
          schema:
            type: string
            format: uuid
      responses:
        '200':
          description: success

In the previous example /uuid-pattern/foobar returns properly an error, which can be casted as multierror with 2 errors but the uuid-format/foobar passes the validation.

Seems like the format is handled in the codebase:

kin-openapi/openapi3/schema.go

Lines 373 to 378 in 46e0df8

	func NewUUIDSchema() *Schema {
	return &Schema{
	Type: TypeString,
	Format: "uuid",
	}
	}

Is there a miss somewhere?

[fenollp]

Hi! Thanks for opening a pull request,
As you noted there, the solution is to DefineStringFormat("uuid", FormatOfStringForUUIDOfRFC4122) before validation.

The OpenAPI spec does not define the uuid format and so handling validation of it out of scope of this lib. Feel free to opt-in to the uuid validation mode though.

[zekth]

Hi! Thanks for opening a pull request, As you noted there, the solution is to DefineStringFormat("uuid", FormatOfStringForUUIDOfRFC4122) before validation.

The OpenAPI spec does not define the uuid format and so handling validation of it out of scope of this lib. Feel free to opt-in to the uuid validation mode though.

So why having email and not uuid then?

[fenollp]

Indeed you're right, this is a mistake as old as the first commit! b855615#diff-90e14c30c1c7403690a666a976d821851020aa362bf984c3d7a6e8e0b2abcca4R22

Thanks for spotting this. I'd accept a PR that removes that line and mentions this change in the README for the next minor version bump.

[zekth]

This is technically a breaking change so having it in minor bump seems wrong. I'd personally leave it like so. Maybe refer this issue in the codebase for the email format definition.

[fenollp]

This is exactly why this exists: https://github.com/getkin/kin-openapi/tree/46e0df8ae84cbb51b7c672a0bb8ebb6995d28c7a#sub-v0-breaking-api-changes