I can't open http://www.elitesecurity.org/ since 2007110103

RESOLVED WORKSFORME

Status

()

Core
HTML: Parser
RESOLVED WORKSFORME
11 years ago
11 years ago

People

(Reporter: Nikola Kocić, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110205 Minefield/3.0a9pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110205 Minefield/3.0a9pre ID:2007110205

When I try to open http://www.elitesecurity.org/ with Minefield 2007110103 or newer it opens wap.elitesecurity.org. Works with IE, Opera and Minefield 2007103103 and earlier.

Reproducible: Always

Steps to Reproduce:
1.Visit http://www.elitesecurity.org/
Actual Results:  
Minefield asks to open wap file

Expected Results:  
Website should open normally

Comment 1

11 years ago
This is just another site that's browser sniffing.  If I change my UA string to Firefox the page works and is served as text/html.  With minefield it is served as text/vnd.wap.wml.  So the change must have occurred on their end.
(Reporter)

Comment 2

11 years ago
But it works normally with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110205 Minefield/3.0a9pre ID:2007103103

If site was browser sniffing it shouldn't work with it either so it seems that there was some change in Minefield behavior since then.

Comment 3

11 years ago
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-10-31+05%3A00%3A00&maxdate=2007-11-01+02%3A00%3A00&cvsroot=%2Fcvsroot

None of the check-ins look suspicious to me, but I just do bug triage.  

I also I tried some of the hourly builds from 10-31 including the last one.  And none of them showed the problem.  So it's puzzling.  Maybe it's one of those problems that doesn't show up until a full build is done.

Also note saving the file gave me this file:  rVMQK+Oe.part  

Perhaps that's another bug.  

Comment 4

11 years ago
Ok it really looks like it's browser sniffing.  

If I change the current build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110212 Minefield/3.0a9pre ID:2007110212

to have the UA string from 10-31:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007103103 Minefield/3.0a9pre

Then the site works.  

Comment 5

11 years ago
I did the same thing Firefox 2.0.0.9.  With giving it a 10-31 minefield UA string it works.  With the UA from after 10-31 it no longer works.  

It's unusual to see browser sniffing by date.  But that seems to be what's happening.  
(Reporter)

Comment 6

11 years ago
OK, this is very confusing:
I tried to change UA string to 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007103103

while using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110205 Minefield/3.0a9pre
site DOESN'T work.

But after updating to 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110212 Minefield/3.0a9pre
and changing UA string to one mentioned above, it works but it doesn't work when I put UA string to default.

Comment 7

11 years ago
I even took FF 2.0.0.9's UA string which is 10-25 and changed only the date to 11-01 an it didn't work.  

Comment 8

11 years ago
My previous comment was while using FF 2.0.0.9 just to be clear.

Comment 9

11 years ago
I'm curious to see what happens when 2.0.0.10 comes out if to see if they update their sniffing with each FF release.  
(Reporter)

Updated

11 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.