Closed Bug 296401 Opened 20 years ago Closed 19 years ago

When I visit cingularrefill.com, I get an error page. When I use Safari, no such problem occurs.

Categories

(Camino Graveyard :: General, defect)

Product:
Camino Graveyard
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Camino1.0

People

(Reporter: saj, Assigned: mikepinkerton)

References

(
URL
)

Details

(Keywords: regression) 

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050531 Camino/0.8+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050531 Camino/0.8+

I am using Camino version 2005053108 (v0.9a1)
I have deleted all cookies and cleared the cache.
The error page message is:
"The Cingular recharge system is having technical issues .  Please be patient as
we work to correct the issues as quickly as possible.  We are sorry for the
inconvenience."

Reproducible: Always

Steps to Reproduce:
1.  Visit http://www.cingularrefill.com


Actual Results:  
There is a redirection to
https://www.myprepaidrefill.com/Cingular/maintenance.htm?aspxerrorpath=/Cingular/default.aspx,
then the error page is displayed

Expected Results:  
When I use Safari, I am presented with a typical Cigular login page (https)

Might be a problem with my Camino configuration, but I believe my configuration
is virgin vanilla.
WFM, 20050531.  Are you accepting cookies?  

I got several requests to accept cookies (approved them all) and also a sheet
warning there was a problem with the site's certificate after clicking on the
link to http://www.cingularrefill.com and ultimately ended up at a login page
https://www.cingularrefill.com/Cingular/Login.aspx?ReturnUrl=%2fCingular%2fsecured%2fAccountSummary.aspx
I am accepting cookies.  "Show cookies" displayed none after all were cleared,
but the list is now growing.

alqahira@mindspring.com reports success in accessing the login page;
sounds like this is a problem specific to either my configuration, OS (Tiger
10.3.9), machine (iMac G4), or combinnation thereof.
(In reply to comment #2)
 
> sounds like this is a problem specific to either my configuration, OS (Tiger
> 10.3.9), machine (iMac G4), or combinnation thereof.

It's most likely either an obscure Camino config (have you tweaked your user.js
or used Camino Extra Prefs to enable "hidden" prefs) or some sort of ISP issue.
 Your issue sounds somewhat similar to the odd behavior described in bug 293095.

Hardware shouldn't matter at all, and FWIW I'm on 10.3.9 also.
I just got a brand new iBook, updated to OSX 10.4.1.
Same failure observed.
Likewise, I'm unable to use Camion (0.8.4 or 6/19 nightly) (OS 10.3.9, dual 2
GHz G5) to access a sign-on page at https://onlinebanking.mandtbank.com

I can access it using Firefox, Safari, or Netscape.  Others can access it from
Camino.  

I've cleared the cache, tried a fresh profile, tried with Camino being the first
application started after a shutdown, etc.

I will always be redirected to a page saying the site is unavailable. 
Interestingly, the visit count hasn't changed since this began.

srb
sblunk@attglobal.net
(In reply to comment #5)
> Likewise, I'm unable to use Camin0 (0.8.4 or 6/19 nightly) (OS 10.3.9, dual 2
> GHz G5) to access a sign-on page at https://onlinebanking.mandtbank.com
> 
> I can access it using Firefox, Safari, or Netscape.  Others can access it from
> Camino.  
> 
> I've cleared the cache, tried a fresh profile, tried with Camino being the first
> application started after a shutdown, etc.
> 
> I will always be redirected to a page saying the site is unavailable. 
> Interestingly, the visit count hasn't changed since this began.
> 
> srb
> sblunk@attglobal.net

I've found that it does not work with 0.8.3, but does work with 0.8.2.

srb
Hmm, bug 293095 also worked for its reporter in 0.8.2.

Comment 5 works fine for me, but as both the site in this bug and the one in bug
293095 WFM, that's no big surprise.

Mike, can you repro either of the two sites mentioned in this bug? (In bug
293095, you could repro at work but not home?)

Steve Johnson: can you get cingularrefill to work if you revert to 0.8.2?  If
so, that would confirm this and bug 293095 are the same.  (Can you check 0.9a1,
released today, as well?)
I can reproduce this using my essentially vanilla "testing" account.  Works in
0.8.2, fails in 0.8.4 and yesterday's nightly, both for Cingular and the bank.

I'm confirming the bug, but my questions in comment 7 still apply.  (I cannot
reproduce bug 293095, however.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Steve J and Steve B: Will you both quit Camino and add the following line to
your user.js file in your user's ~/Library/Application Support/Camino folder (if
the file does not exist, create a *plain text* file with that name):

user_pref("intl.accept_languages", "en-us,en");

Save the file, restart Camino, and visit cingular/your bank.  Does it work now?
 (It does for me in my testing account.)  If so, can you also open your System
Prefs and go to the international pane and tell me the number of languages that
appear in the box in the language tab.

Bruce D: It appears that when there are too many languages present in system
prefs, *no* accept-language string is being sent
(http://gemal.dk/browserspy/accept.php), and the sites are somehow choking on
this.  Before you added the accept-language detection in 0.8.3, Camino always
sent en-us,en if there was no user_pref("intl.accept_languages", ...) set.
I am currently running 0.9a1 on both my iMac G4 and iBook.
I have also tried 8.4 on the iBook (same problem observed).
I am not sure how to obtain older versions (I.E 8.2) of Camino - is there an
archive available?
(In reply to comment #10)
> I am not sure how to obtain older versions (I.E 8.2) of Camino - is there an
> archive available?

Yes, http://ftp.mozilla.org/pub/mozilla.org/camino/releases/

The user_pref line worked like a charm.  I have 15 languages listed in the
International pane (only one of which I can read; I've just never gotten around
to thinning them out).

Thanks

srb
It's working; I created a file called user.js containing the line:
user_pref("intl.accept_languages", "en-us,en");

In System Prefs - international pane I observe 15 languages that
appear in the box in the language tab.
Bruce, will you be able to fix this for 0.9?

I'm putting this on the 1.0 list so it doesn't get lost (it is a regression, but
it has a work-around).

Samuel, if this doesn't get fixed for 0.9, the work-around (either decrease the
number of languages checked in the System Prefs International pane or set the
Gecko accept-string-pref manually in user.js) should probably show up in the
release notes.
Target Milestone: --- → Camino1.0
So this accept-language fallout?
WFM. My accept-lang pref is:

user_pref("intl.accept_languages",
"en,ja,fr,de,es,it,nl,sv,no,da,fi,pt,zh-cn,zh-tw,ko");
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
At some point it looks like we were failing to set an accept-lang pref or
setting it to a blank/empty string if there were a large number (15 is the Mac
OS X default) of languages enabled.

This is WFM now with the 1.8 branch using my testing account (without the
work-around), too, but I can't recall any change that fixed/touched this
issue--at least not since late June when I diagnosed this.  I'd feel better if
someone (Bruce/Simon) could assure me we have some sort of fallback/protection
code in place to ensure we're never in a situation where intl.accept_languages
is missing or blank ("" or " ").

See also bug 293095, which I think was caused by the same issue but which no one
who could originally repro it has ever updated.
You need to log in before you can comment on or make changes to this bug.