Structured parsing of the Origin header (issue #2007) #2082
This PR improves the parsing of the
Instead of being interpreted as a string, the header is now interpreted as a list of items of type
We commonly think of the Origin as containing a single host. According to the Mozilla Developer page, however, the header may be an empty string (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin). And according to the RFC, it may contain multiple hosts (https://tools.ietf.org/html/rfc6454#section-7).
There's one last complication. The RFC technically states that
Work done in conjunction with Hosam Aly (@hosamaly) at Syntactic Sugar, London. Instead of being interpreted as a string, the Origin header is now interpreted as a "null" header or a non-empty list of "hosts" as specified in the RFC: https://tools.ietf.org/html/rfc6454#section-7 Note that we don't use `Uri` to model the hosts because the RFC states that only a scheme, host, and port are acceptable. The following MDN article is the first hit on Google. It states that the empty string is a valid Origin header. While this is technically incorrect, we do permissively parse the empty string as a null header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin This PR also updates some tests in CORSSpec that erroneously added a trailing slash to headers in their test data.