Question

我有一个应用程序，它使用带有CORS的POST请求来支持后端服务（从www.mydomain.com到api.mydomain.com）。后端由Tomact8服务器提供，CORSResponseFilter已实现如下：

public class CORSResponseFilter implements ContainerResponseFilter {

   public void filter( ContainerRequestContext requestContext, ContainerResponseContext responseContext ) throws IOException {

       MultivaluedMap< String, Object > headers = responseContext.getHeaders();

       headers.add( "Access-Control-Allow-Origin", "*" );
       headers.add( "Access-Control-Allow-Methods", "POST" );
       headers.add( "Access-Control-Allow-Headers", "X-Requested-With, Content-Type" );
    }
}

一切正常，除了iOS上的Chrome（Android上的Chrome正在运行！）。对于这个特定的客户端，Tomcat似乎拒绝回应飞行前的OPTION请求。在下面显示了来自Tomcat的访问日志：

10.10.10.9 - - [14/Sep/2015:20:55:45 +0200] "OPTIONS /api HTTP/1.1" 200 - "Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) CriOS/45.0.2454.68 Mobile/13B5110e Safari/600.1.4"
10.10.10.1 - - [14/Sep/2015:20:56:29 +0200] "OPTIONS /api HTTP/1.1" 200 561 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36"

第二行显示了应该是的请求，可以看到在第一种情况下响应没有大小，因此我认为根本没有发送任何内容，其中第二个调用正在接收561字节的响应。 / p>

我不知道更好的方法，然后我们调试iOS上的Chrome，它只显示POST请求启动但后来从未收到响应（尽管Tomcat只收到OPTIONS请求而没有关注POST）

在客户端，superagent库用于HTTP次调用。我不知道这个问题是由Tomcat服务器本身还是由客户端/浏览器引起的，因为它只发生在某个设备/浏览器组合中（iOS上的Chrome）

有没有人遇到过类似的行为，并且能指出我丢失的位？

PS：是的，iPhone正在运行预发布iOS，但普通iOS版本也是如此

更新：使用WireShark我可以从桌面和移动设备中提取OPTIONS请求的标头。

来自CriOS的

：

Connection: keep-alive
Access-Control-Request-Headers: accept, origin, content-type
Access-Control-Request-Method: POST
Accept: */*,image/webp
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) CriOS/45.0.2454.89 Mobile/13B5110e Safari/600.1.4
Accept-Encoding: gzip, deflate, sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4

来自桌面：

Connection: keep-alive
Access-Control-Request-Method: POST
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.93 Safari/537.36
Access-Control-Request-Headers: accept, content-type
Accept: */*
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4,ru;q=0.2

我注意到的是ACCEPT标题中的 image / webp mediatype，但它还有 * / * ，所以我不是确定这是否相关......

Answer 1

参考Why does Chrome for iOS insert image/webp content-type?我可以通过操纵服务器本身的请求标题来解决这个问题：

public class CroISRequestFilter implements ContainerRequestFilter {

    @Override
    public void filter( final ContainerRequestContext requestContext ) throws IOException {

        if (requestContext.getHeaders().getFirst( "accept" ).equals( "*/*,image/webp" )) requestContext.getHeaders().putSingle( "accept", "*/*" );
    }
}

此过滤器只会将任何 * / *，image / webp 内容类型覆盖为直接 * / * ，从而允许服务器以文本/ plain ，它在客户端启用CORS（CriOS）。

Tomcat 8没有响应来自CriOS的OPTIONS请求

1 个答案: