Fix AllowedOrigins according to RFC 6454

[GeorgeCGV]

• Transformation of the origin into uri components used
  to fail with a NumberFormatException when origin string
  contained a character after the port definition like [port]/.
  • The slash straight after the port will ruin the integer parsing.
    DefaultCorsProcessor.processRequest will fail during call to WebUtils.isSameOrigin.
• Origin validity check was considering
  'http://domain1.com' and 'http://domain1.com/' to be different. The same applies to allowed origins comparison. This doesn't meet RFC 6454 standard.

3.2.1. Examples

All of the following resources have the same origin:

http://example.com/
http://example.com:80/
http://example.com/path/file

Notes

1. In order to improve performance the allowedOrigins collection can convert provided Strings directly to UriComponents or parsing for the header origin and allowedOrigins can be further simplified.
2. I'm not totally sure about UriComponentsBuilder.fromHttpRequest but based on the code it may fail the same way as UriComponentsBuilder fromOriginHeader did. It depends what value can be stored in X-Forwarded-Host.

Issue: Nothing has been reported so far. However, the issue becomes noticeable: SocketRocket

I have signed and agree to the terms of the SpringSource Individual
Contributor License Agreement.

[rstoyanchev]

Thanks for the pull request. Would you mind creating a ticket in our JIRA issuer tracker?

[GeorgeCGV]

@rstoyanchev sure, here we go: Jira Issue - SPR-13478.

[sdeleuze]

Resolved by this commit, so I close this PR. Thanks for raising this issue.