tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Terence M. Bandoian" <>
Subject Re: CORS issue with Tomcat and Android Webview
Date Mon, 28 Apr 2014 19:44:15 GMT
On 4/27/2014 11:36 AM, Konstantin Kolinko wrote:
> 2014-04-27 0:50 GMT+04:00 Terence M. Bandoian <>:
>> On 4/26/2014 1:13 AM, Ankit Singhal wrote:
>>> On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian
>> Hi, Ankit-
>> Where did you see <accept-origin> documented?  I see an <init-param>
>> on the Tomcat web site:
>> In any case, I agree that if allowed origins is set to "*", all CORS
>> requests should be allowed.  As I understand it, the W3C spec only requires
>> that the Origin header exists:
>> It also states that it is acceptable for Origin headers to always match the
>> list of allowed origins when the list is "unbounded".
> 1. From a quick reading, I do not see any syntax for that lists
> besides exact case-sensitive matches.
> says that the syntax of origin header is
>     serialized-origin   = scheme "://" host [ ":" port ]
>                         ; <scheme>, <host>, <port> from RFC 3986
> Nothing says that "host" can be omitted.
> Per Sections 6.1 and 6.2 the correct serialized value of such
> "file://" origin will be "null".
> 2. Some form of sanity check must be present,
> because the origin header value is sent back to client and as such can
> be abused.
> 3. That said,
> I think that CorsFilter.isValidOrigin(String) can be patched to
> a) Be more strict to the specified syntax  (and not just allow any URI)
> (Not actually necessary, but it will allow to reject non-conforming clients).
> b) Specifically white-list the "null" origin.
> c) Specifically white-list a "file://" origin,  with notion that that
> is a bug in certain Android versions
>> Maybe this is a good case to submit a bug report or a patch.
> Agreed.
> Best regards,
> Konstantin Kolinko

Hi, Konstantin-

I agree there is value in validating the origin header value and with 
your interpretation of the IETF origin header specification.  I was 
referring to:

which includes:

     1. If the Origin header is not present terminate this set of steps. 
The request is outside the scope of this specification.

     2. If the value of the Origin header is not a case-sensitive match 
for any of the values in list of origins, do not set any additional 
headers and terminate this set of steps.

         Note: Always matching is acceptable since the list of origins 
can be unbounded.

The solution you propose makes sense to me and I think will work 
although I'm a little unclear about a).  Do you mean adding a test for a 
null host value?

-Terence Bandoian

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message