Closed Bug 637395 Opened 14 years ago Closed 14 years ago

morningstar.es (and other Morningstar sites) - bad UA sniffing causes redirect to WAP site, browser served incorrect MIME type

Categories

(Tech Evangelism Graveyard :: Spanish, defect)

Product:
Tech Evangelism Graveyard
Component:
Spanish
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: alvaro.segura, Unassigned)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12 Build Identifier: 4.0b12 The above URL happens to use a "301 Redirect" to another page. That page, being HTML, is not displayed, but the "Open or download" dialog window appears. As if the MIME type is not recognized. I think it's a regression. Used to work until a few betas ago. Though I can't confirm it hasn't been a change in that website. Other browsers show that website fine. Reproducible: Always Steps to Reproduce: 1. Go to http://www.morningstar.es/ Actual Results: The browser asks for open or download file. Expected Results: HTML page is displayed Seems related to Bug 375701
Confirmed that Firefox 3.6 handles that site correctly. The bug seems to be in Firefox 4 beta. Also, the related bug is about ColdFusion, but here it's ASP.
grr, this is the third or fifth page with the same bug and they all use IIS. via http://web-sniffer.net and "your user agent" (Mozilla/5.0 (Windows NT 6.1; rv:2.0b13pre) Gecko/20110228 Firefox/4.0b13pre SeaMonkey/2.1b3pre) Status: HTTP/1.1 200 OK Connection: close Date: Mon, 28 Feb 2011 19:59:07 GMT Server: Microsoft-IIS/6.0 cache-control: private X-Powered-By: ASP.NET X-AspNet-Version: 2.0.50727 X-Powered-By: UrlRewriter.NET 2.0.0 Set-Cookie: RT_es_LANG=es-ES; domain=morningstar.es; expires=Tue, 28-Feb-2012 00:00:00 GMT; path=/ Set-Cookie: ASP.NET_SessionId=csa5w1eyalli4quo5jos1p55; path=/; HttpOnly Cache-Control: private Content-Type: application/vnd.wap.xhtml+xml; charset=utf-8 Content-Length: 62896 They send us application/vnd.wap.xhtml+xml that we don't support because we are not a wap browser. If you change the User agent you get : Status: HTTP/1.1 200 OK Connection: close Date: Mon, 28 Feb 2011 20:01:33 GMT Server: Microsoft-IIS/6.0 cache-control: private X-Powered-By: ASP.NET X-AspNet-Version: 2.0.50727 X-Powered-By: UrlRewriter.NET 2.0.0 Set-Cookie: RT_es_LANG=es-ES; domain=morningstar.es; expires=Tue, 28-Feb-2012 00:00:00 GMT; path=/ Set-Cookie: ASP.NET_SessionId=0b1fpo45lx25jvzdm1fzhefp; path=/; HttpOnly Cache-Control: private Content-Type: text/html; charset=utf-8 Content-Length: 62896 This is most likely triggered by the "pre" in the UA. The stupid server must think that we are a PALM PRE or something like that. This will work again if the "pre" is removed for Gecko2.0 final. marking invalid, this is a server bug
URL: http://www.morningstar.es/ → http://www.morningstar.es/es/
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Well, the server should fix this...
Assignee: nobody → spanish
Severity: major → normal
Component: Networking: HTTP → Spanish
OS: Windows XP → All
Product: Core → Tech Evangelism
QA Contact: networking.http → spanish
Hardware: x86 → All
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Also, comment 12 says b12, not b13pre, right? Alvaro, are you seeing this in b12 itself? If so, this is not the "pre" issue...
However I can confirm that I get the WAP thing even with the b12 UA in comment 0. The reason for that is that the "Windows;" part that used to come before "Windows NT 5.1" is gone. So still a site bug, but triggered by a UA change on our end. And this will be a problem in final too, on Windows only.
Ccing some people who may be interested in the evang and UA aspects of this.
You are right, should I reopen the 3-5 other pages with the same issues and send them to tech evangelism ? They should be easy to find if you search with "application/vnd.wap" in the last year.
> You are right, should I reopen the 3-5 other pages with the same issues Yes.
The change on our end that confuses this site's UA-sniffing is bug 581783.
Blocks: 581783
i found 3 bugs, bug 541925 (old and for 3.6), bug 636977 (http://www.morningstar.co.uk) and bug 636963 (http://www.morningstar.it) and I'm sure that there is one more bug that I can't find at the moment where the "pre" triggered the issue. I think it should be ok to handle all 3 morningstar reports in one bug.
This happens in 4b12. I think it was fine until 4b8 or something like that (and ff 3.6). Anyway it's strange. Before submitting I did a "wget -S" to see if there was a wrong MIME type from the server and I got this: Connecting to www.morningstar.es[62.190.147.130]:80... connected. HTTP request sent, awaiting response... 1 HTTP/1.1 301 Moved Permanently 2 Connection: keep-alive 3 Date: Tue, 01 Mar 2011 15:51:32 GMT 4 Server: Microsoft-IIS/6.0 5 cache-control: private 6 X-Powered-By: ASP.NET 7 X-AspNet-Version: 2.0.50727 8 X-Powered-By: UrlRewriter.NET 2.0.0 9 Location: /es/ 10 Set-Cookie: ASP.NET_SessionId=0y0b4pvmhnb2ixmsgyyjuz45; path=/; HttpOnly 11 Cache-Control: private 12 Content-Length: 0 Location: /es/ [following] --16:51:32-- http://www.morningstar.es/es/ => `index.html.1' Connecting to www.morningstar.es[62.190.147.130]:80... connected. HTTP request sent, awaiting response... 1 HTTP/1.1 200 OK 2 Connection: keep-alive 3 Date: Tue, 01 Mar 2011 15:51:32 GMT 4 Server: Microsoft-IIS/6.0 5 cache-control: private 6 X-Powered-By: ASP.NET 7 X-AspNet-Version: 2.0.50727 8 X-Powered-By: UrlRewriter.NET 2.0.0 9 Set-Cookie: RT_es_LANG=es-ES; domain=morningstar.es; expires=Thu, 01-Mar-2012 00:00:00 GMT; path=/ 10 Cache-Control: private 11 Content-Type: text/html; charset=utf-8 12 Content-Length: 63175 Content-Type is text/html, isn't it? Why don't I see tha wap thing?
Ha,ha. I now tried passing the UA string given by Firefox: wget -S -U "Mozilla/5.0 (Windows NT 5.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12" www.morningstar.es And the response is: 12 Content-Type: application/vnd.wap.xhtml+xml; charset=utf-8 IIS is interpreting Firefox's UA string to be a wap browser and giving different content type!
Fixing summary.
Summary: 301 Redirect causes download of page HTML code → morningstar.es (and other Morningstar sites) - bad UA sniffing causes redirect to WAP site, browser served incorrect MIME type
This was a problem with our mobile redirect portion of code. I've updated it and all morningstar sites seem to be working in Firefox 4.0b12 now. Thanks for pointing out the problem. Iain Jones Morningstar Dev
Thanks for fixing the problem and that you commented in this bug report ! I can confirm that the problem is fixed.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
(In reply to comment #14) > This was a problem with our mobile redirect portion of code. I've updated it > and all morningstar sites seem to be working in Firefox 4.0b12 now. Based on comment 5, it sounds like other Windows-based Gecko browsers could also be affected. Has anyone tested in, for example, Seamonkey?
(In reply to comment #16) > (In reply to comment #14) > > This was a problem with our mobile redirect portion of code. I've updated it > > and all morningstar sites seem to be working in Firefox 4.0b12 now. > > Based on comment 5, it sounds like other Windows-based Gecko browsers could > also be affected. Has anyone tested in, for example, Seamonkey? I've tested it with the latest version of seamonkey and it works ok. The fix I made was to the code on the Morningstar server. Specifically, it used to check the UserAgent for the string "Windows;" but it appears that this has changed in Firefox 4.0b to be something like "Windows NT 5.1;", so any Gecko browser should display the site ok now.
(In reply to comment #17) > I've tested it with the latest version of seamonkey and it works ok. Thanks. Just wanted to make sure Firefox wasn't the only browser tested (as so many webdevs seem to do). :)
I'm glad to say I'm not normally one of those webdevs :) Although I had drawn the line at testing with beta browsers, that is going to change as from now :)
Verified fixed. Iain, thank you!
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.