为什么iOS版Chrome会插入图片/ webp内容类型？

Question

I have a mobile web app that is making an AJAX request via $.get(). The request succeeds for Safari iOS, but fails for Chrome for iOS with status 0 and statusText "error".

Using tcpdump on my server, I can see that Safari sends/receives the following headers:

Accept: */*    (outgoing)

Content-Type: text/plain;charset=ISO-8859-1    (returning)

Chrome for iOS adds a mime type of "image/webp" to the outgoing Accept: header and the Content-Type returned is "image/webp":

Accept: */*,image/webp  (outgoing)

HTTP/1.1 200 OK
Content-Type: image/webp   (returning)

Reading through the jQuery code, it looks like $.get() only parses certain content types in AJAX responses, so I'm thinking that an image mime type is just being rejected, resulting in the "error" status.

In the request from Chrome for iOS as it arrives on my server, there's also this header:

Via: 1.1 Chrome-Compression-Proxy

...which indicates that Chrome for iOS has sent the request to a Google proxy server to service the request (info https://support.google.com/chrome/answer/3517349?hl=en ). Seems like this proxy server is setting the extra content type, and somehow the content type is returned as image/webp on the way back? The server code is RESTful Spring 3; I do set the content type as "text/plain" in the controller code, but somehow that's not being taken and it's still returning as "image/webp".

Has anyone had a similar problem and found a solution for it? I need to have a return Content-Type of "text/plain" to get the data back correctly to my app. This request works correctly on Chrome for Android as well AFAIK, haven't done a tcpdump for that, but the app works correctly; only fails on Chrome for iOS.

Answer 1

We are encountering the same issue: Chrome for iOS prefers webp, so it sends its headers as Accepts: image/webp, */*;q=0.8 . The people implementing that change apparently never thought about the impact, so this causes quite a number of API's to return a 415

For more information see: https://code.google.com/p/chromium/issues/detail?id=169182

In the end we modified the server itself, since it would return a 415. On the response side, it should all go well.