Closed Bug 582630 Opened 14 years ago Closed 10 years ago

appstorehq.com - sniffs for "pre" and refuses to load if present

Categories

(Web Compatibility :: Site Reports, defect)

All
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: breckard, Unassigned)

Details

Developer Profile URL's for appstorehq do not load page content in minefield.

Example:
http://www.appstorehq.com/lukeshan-35039/developer

Seems fine in FFx3.6 and in Chrome.  Probably a site issue, but can someone take a look?
This page doesn't load for me in nightlies going back to 2007.  I didn't test further.  Spoofing the Firefox 3.6 UA makes it work.  Also of interest:

% wget --user-agent "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; en-US; rv:2.0b2pre) Gecko/20100717 Minefield/4.0b2pre" -O /dev/null 'http://www.appstorehq.com/lukeshan-35039/developer'
--2010-07-28 12:30:03--  http://www.appstorehq.com/lukeshan-35039/developer
Resolving www.appstorehq.com... 174.129.211.97
Connecting to www.appstorehq.com|174.129.211.97|:80... connected.
HTTP request sent, awaiting response... 406 Not Acceptable
2010-07-28 12:30:04 ERROR 406: Not Acceptable.

Removing the two instances of "pre" from the UA string makes things work, of course...
Assignee: nobody → english-us
Component: General → English US
Product: Core → Tech Evangelism
QA Contact: general → english-us
Version: Trunk → unspecified
Bret: does this work in the 4.0 Beta? It should, if I'm understanding comment 1 correctly.
Does not load in:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b3pre) Gecko/20100728 Minefield/4.0b3pre

downloading beta now.
Loads fine in:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b2) Gecko/20100720 Firefox/4.0b2

false alarm?
This is still stupid site behaviour. If they're trying to exclude Palm Pre users, they should be sniffing specifically for the Pre's browser, not the generic string "pre".
Hardware: x86 → All
Summary: Page not loading in Nightlies - Works fine in 3.6 and Chrome → appstorehq.com - sniffs for "pre" and refuses to load if present
This is a _very_ common issue recently.  Can we stop using that string in our nightly UA?  :(
Not trivially, but yes, though I think that's a different bug - let's leave this one about tracking the TE for this site, please.
Fair.  Filed bug 582672.
The web site doesn't exist anymore.
It redirects to http://www.mobiledevhq.com/?utm_medium=AppStoreHQ
Assignee: english-us → nobody
Status: NEW → RESOLVED
Closed: 10 years ago
Component: English US → Desktop
Resolution: --- → INVALID
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.