URL like http://example.com:1234/ and http://example.com:1234 should treated as same origin [1]. It is not true in current implementation. We compare the CORS origin literally without normalizing the string given by user through EnableCors therefore cause CORS rejection which is difficult to find.
The schema of origin is restrictively defined hence we can normalize the user setting. Matching / Comparing origins are defined in RFC6454 [2]
[1] http://tools.ietf.org/html/rfc6454#section-4
[2] http://tools.ietf.org/html/rfc6454#section-5
Comments: We added the validation so that users can provide only valid origins. E.g. http://example.com:1234/ would not be a valid origin even though it's a valid URL. Browser clients would not send the origin header with the trailing slash. The checkin that added the validation was: https://aspnetwebstack.codeplex.com/SourceControl/changeset/81f62d902e4c0b22839c0c0a4d5657fde5876497
The schema of origin is restrictively defined hence we can normalize the user setting. Matching / Comparing origins are defined in RFC6454 [2]
[1] http://tools.ietf.org/html/rfc6454#section-4
[2] http://tools.ietf.org/html/rfc6454#section-5
Comments: We added the validation so that users can provide only valid origins. E.g. http://example.com:1234/ would not be a valid origin even though it's a valid URL. Browser clients would not send the origin header with the trailing slash. The checkin that added the validation was: https://aspnetwebstack.codeplex.com/SourceControl/changeset/81f62d902e4c0b22839c0c0a4d5657fde5876497