Closed Bug 101054 Opened 23 years ago Closed 22 years ago

WRMB: Page reloads forever.

Categories

(Core :: Networking: HTTP, defect, P1)

x86
Windows 98
defect

Tracking

()

VERIFIED WORKSFORME
mozilla0.9.9

People

(Reporter: mgalli, Assigned: badami)

References

()

Details

(Keywords: topembed, Whiteboard: [bugscape: 8433])

Attachments

(1 file)

I am investigating why this page keeps reloading forever with Mozilla. This may
be a evang case or have a product related issue. I am asking for help because I
will contact this company in case is evang. 

Go to the URL and you will see the page reloading and reloading trying to access
the HTTPS URL. After many attempts to see the source-code I was able to copy and
paste this source code:

---------
<html><head><meta http-equiv="Refresh" content="0;
url=https://secure.insure.statefarm.com/cgi-bin/sfarm/vin/fortecgi?ServiceName=VINSHTTPAccessSO&amp;TemplateName=vintpl/common/vins_auto_logon.tmpl&RedirectTo=https%3A%2F%2Fsecure%2Einsure%2Estatefarm%2Ecom%2Fcgi%2Dbin%2Fsfarm%2Fvin%2Ffortecgi%3FServiceName%3DVINSHTTPAccessSO%26TemplateName%3Dvintpl%2Fcommon%2Frenters%2Frrq%5Fwelcome%2Etmpl%26StateProv%3DIL%3E"></head><body></body></html>
---------

Note that the page do a refresh to the same page. But with IE, this is not the
case, the the source code is actually the real page.
Hunm.... I am sorry.. is not the same page .. actually the reload is to a
different page...
Summary: Page reloads forever. → Page reloads forever.
->network
Assignee: asa → neeti
Component: Browser-General → Networking
QA Contact: doronr → benc
I think refresh = 0 means refresh after zero seconds...

but I am also marking this "NEW" b/c it happens to me.
Status: UNCONFIRMED → NEW
Ever confirmed: true
setting topembed. 
Keywords: topembed
darin
Assignee: neeti → darin
investigating for moz 0.9.6
Priority: -- → P1
Target Milestone: --- → mozilla0.9.6
adding keywords
Summary: Page reloads forever. → WRMB: Page reloads forever.
perhaps this has something to do with the way we escape URLs?!?
The redirecting url on the htmlpage contains a & that is html-escaped to &amp;
This *may* cause the problem ... 
andreas: thanks for spotting that... let me see what 4x does.
Status: NEW → ASSIGNED
ok, because this is SSL, it's difficult to see what 4x is doing... however, we
are definitely converting "&amp;" to "&" before writing out the request on the
wire.  seems like that might not be the intent of the content provider, since
the URL contains the "%amp;" as well as a couple "&" further along in the URL. 
i'll setup a plaintext testcase to see what 4x does.
hmm.. looks like 4x also converts a "&amp;" in a href to "&" .. so there must be
something else causing this.
Seems the &amp; is a dead end. It's correctly converted. Currently I don't think
it's an escape problem. Is it possible to get a similar log with NS4 or IE?
i don't know of any way to extract the HTTP transaction data from 4x or IE...
though i believe there is a way to do it with lynx, and i was able to browse to
the site using lynx.. so, perhaps i might be able to learn something by
observing what lynx does.
adding bugscape ref
Whiteboard: [bugscape: 8433]
Blocks: 64833
removing topembed. the underlying bugscape bug is P2.
However, I would hate to leave this unresolved. is there anything for the
evangelism team? how long would it take to investigate?
Keywords: topembed
it'll be easily a few days before i get around to investigating this one again.
this problem may be a standards violation on the part of the website, or it may
be that mozilla is incorrectly escaping URLs.
Not sure if this will help you guys: 
-----------------------------------

The loop problem alternates between two URLs (the one described above and the
following one). If you enter the following one before the original URL: 

(2)
https://secure.insure.statefarm.com/cgi-bin/sfarm/vin/fortecgi?ServiceName=VINSHTTPAccessSO&TemplateName=vintpl/common/vins_auto_logon.tmpl&RedirectTo=https%3A%2F%2Fsecure%2Einsure%2Estatefarm%2Ecom%2Fcgi%2Dbin%2Fsfarm%2Fvin%2Ffortecgi%3FServiceName%3DVINSHTTPAccessSO%26TemplateName%3Dvintpl%2Fcommon%2Frenters%2Frrq%5Fwelcome%2Etmpl%26StateProv%3DIL%3E

Then you will be able to enter the original URL without the repeat problem.
so i tried to reproduce this problem using the 2001103103 mozilla nightly build
under win2k and couldn't.  the page seems to always finish loading.  ... will
try to reproduce using a win98 machine.
tested with the 2001102903 build under win98 and could not reproduce this bug.

marking WORKSFORME.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Processing hang still exists NS 2001011703. REOPENING.

Cannot replicate always but happens often and randomly (ie not any 1 particular
state selected causes it).

Also browser crashed a couple times on that site. Not sure if related to this issue.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Bugscape 8433
-> badami
Assignee: darin → badami
Status: REOPENED → NEW
Target Milestone: mozilla0.9.6 → mozilla0.9.9
This seems to work for me.
Both the above mentioned URL and browsing about the site randomly.

Are there any explicit steps required to reproduce this bug ?
Keywords: nsbeta1+
This seems to work for me and I have not heard back any responses for comment 25
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → WORKSFORME
verifying wfm, if someone can reproduce this consistantly please reopen
Status: RESOLVED → VERIFIED
(Reopening for further comments)

I was only able to consistently replicate this in Mozilla/5.0 (Windows; U; 
Windows NT 5.0; en-US; rv:0.9.4.2) Gecko/20020131   
(please see http://bugscape.mcom.com/show_bug.cgi?id=8433#c31 if you can)

If you have any clue of a bug that may have fixed this problem please let me 
know so I can mark it topembed.

1. Go to statefarm.com
2. click Renters, under Get Online Quotes
3. Pick Illinois from the pull down (Note the "Netscape user" warning on this 
page)

REsult: Endless "Processing please wait" 

(However if you hit Back then Forward the form loads)
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
removing myself from the cc list
-> http.
Component: Networking → Networking: HTTP
Whiteboard: [bugscape: 8433] → [bugscape: 8433][adt1]
Removing ADT1, and marking as nsbeta1-. This sounds like a WFM, since it can
only be can't be reproduced on current builds, and appears to be a bug looking
for a problem (with a resolution). Pls let us know, if this opos up again.
Status: REOPENED → RESOLVED
Closed: 23 years ago22 years ago
Keywords: nsbeta1+nsbeta1-, topembed
Resolution: --- → WORKSFORME
Whiteboard: [bugscape: 8433][adt1] → [bugscape: 8433]
QA Contact: benc → tever
verified wfm - tested mozilla 09/11/02 build on winNT4 - according to Susies
comment in bugscape 8433 this is working for her too
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: