Having re-read the specs I can see that trying to match origins by
resolving to IP addresses is not a good idea.

However, that still leaves us with a problem because Chrome sends an
Origin header for some same-origin requests. The CorsFilter denies
these requests if the origin is not in cors.allowed.origins.  We have
too many possible origins to be able to specify them all in the
deployment descriptor (and we don't want to allow all origins).

One solution would be to treat requests as non-CORS when the Origin
and Host headers match (having pre-appended the request scheme to the
Host header).
Do you think that this is something that Apache would consider
incorporating into the CORS filter? This would be preferable to
maintaining our own copy of the filter indefinitely.

Thanks
Richard

On Mon, Mar 10, 2014 at 3:55 PM, Mark Thomas <ma...@apache.org> wrote:
> On 10/03/2014 14:30, Richard Hart wrote:
>> (Tomcat 7.0.50, Linux)
>>
>> Having recently enabled CORS support for our Tomcat-based web app
>> using the provided CorsFilter, we have discovered a problem where some
>> same-origin (i.e. non-CORS) requests from certain browsers (e.g.
>> Chrome) are denied.  This is due to the browser setting the Origin
>> header even though the request is non-CORS.  it turns out that this is
>> in fact legal according to RFC 6454.
>>
>> Given the popularity of Tomcat and Chrome I was surprised to find
>> little mention of this problem online.  Has anyone else encountered
>> this problem?
>>
>> Our planned solution is to fork CorsFilter and and modify it to allow
>> requests for which the Origin and Host headers both resolve to the
>> same IP address.  However, if somebody has already implemented a
>> solution for this problem could you please let us know.
>
> If the Origin and Host headers don't match (even if they do resolve to
> the same IP address) isn't that a cross-origin request? In which case
> isn't the filter doing what it is meant to?
>
> Why isn't setting the cors.allowed.origins init parameter sufficient?
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to