Closed Bug 563 Opened 26 years ago Closed 25 years ago

Redirects don't work

Categories

(Core :: Networking, defect, P1)

Product:
Core
Component:
Networking
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: angus, Assigned: ramiro)

References

(
URL
)

Details

We need to enable redirects in order to browse some of the top sites that use
redirects. For example, almost all banner ads use a redirect (you click, it logs
the ad, and redirects you to the advertister site).
reassigning to rpotts since he's the netlib guru...
Orignal test case url was: http://warp/bonsai

http://warp/bonsai actually takes you through multiple redirects.
http://warp/bonsai <enter> gives you an http redirect which works (it takes you
to the page that tells you you're going to be redirected). This page is
http://warp.netscape.com/webtools/bonsai/ which contains an html http-equiv meta
tag with "Refresh". This is the redirect that is broken.

There are three types of redirects:
1. http redirects (302 "temporarily moved" server responses) - These are working
as they are netlib dependent. Here's an example of one: http://warp/bonsai
2. javascript redirects - javascript implementation dependent. Last time I tried
(http://people.netscape.com) this wasn't working.
3. http-equiv "Refresh" meta tag redirect - These are broken as our current
parsing code doesn't prompt the reload (I'm not sure where it's actully parsing
them yet). The windows front end on gromit sets a timer that refreshes the url
every X seconds, or once (essentially a redirect). We don't have an equivelent
yet in raptor.
The previous example of a javascript example is no good. Use
http://lotus/jsredirect.html . If you see the text "jsredirectdest.html" you
were successfully redirected.
Adding vidur to the "cc:" list since he will probably hook up the
window.location= type of "redirect," if it's even right to call it that.
Yeah, window.location is next on my list. It won't be there for upcoming demo,
though.
302 redirects don't work. For a test case, try clicking the "My Netscape" button
on the Netscape home page. I wasn't sure if Jud was aware of this issue, so I'm
making note of it here.
I'm confused. The my netscape button doesn't do a redirect at all. 302's work
except for a glitch I have to check in. (www.pcmagazine.com doesn't work even
thought it's a 302).
Apologies for the confusion - you're right, the My Netscape button on our home
page doesn't do a 302 redirect. It's also a link in a client-side image map,
which could be complicating things. Currently, you click on the button, and it
loads this URL:

http://home.netscape.com/netcenter/personalize/index.html

Which tries to "redirect" you to my.netscape.com using this code either
JavaScript or META refreshes:

<SCRIPT LANGUAGE="JavaScript1.1">
<!--
document.location.replace("http://my.netscape.com/index.html");
//-->
</SCRIPT>
<META HTTP-EQUIV="Refresh" CONTENT="0; URL=http://my.netscape.com/index.html">
I'll take the bug. I already checked in window.location. document.location is a
short step behind. Angus, could you check it out again after I commit my changes
today?
I just checked in my fix for this (8/13/98 1:13pm) into the tip. It fixes
redirects that come in via meta http-equiv refresh tags.
My test case involves going to www.netscape.com and clicking on the "My
Netscape" icon at the head of the page. I crash when doing this now. The stack
trace is as follows:

nsHTMLTagContent::AddScriptEventListener(nsIAtom * 0x01064cc0, nsHTMLValue &
{...}, const nsID & {...}) line 408 + 11 bytes
nsHTMLTagContent::SetDocument(nsIDocument * 0x0119cd40) line 265
nsHTMLContainer::AppendChild(nsHTMLContainer * const 0x0118d590, nsIContent *
0x0118d690, int 0) line 195
HTMLContentSink::AppendToCorrectParent(nsHTMLTag eHTMLTag_font, nsIHTMLContent *
0x0118d590, nsHTMLTag eHTMLTag_a, nsIHTMLContent * 0x0118d690, int 0) line 1452
HTMLContentSink::CloseContainer(HTMLContentSink * const 0x01470c08, const
nsIParserNode & {...}) line 909
CNavDTD::CloseContainer(const nsIParserNode & {...}, nsHTMLTag eHTMLTag_a, int
1) line 2640 + 22 bytes
CNavDTD::CloseContainersTo(int 18, nsHTMLTag eHTMLTag_a, int 1) line 2674 + 20
bytes
CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_a, int 1) line 2695 + 20 bytes
CNavDTD::HandleEndToken(CToken * 0x0115c600) line 933 + 17 bytes
NavDispatchTokenHandler(CToken * 0x0115c600, nsIDTD * 0x01455600) line 419 + 12
bytes
CTokenHandler::operator()(CToken * 0x0115c600, nsIDTD * 0x01455600) line 80 + 14
bytes
CNavDTD::HandleToken(CNavDTD * const 0x01455600, CToken * 0x0115c600) line 679 +
18 bytes
nsParser::BuildModel() line 586 + 16 bytes
nsParser::ResumeParse() line 551
nsParser::OnDataAvailable(nsParser * const 0x0119c214, nsIURL * 0x01196e80,
nsIInputStream * 0x0119c970, int 7300) line 761 + 15 bytes
nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x01196e20,
nsIURL * 0x01196e80, nsIInputStream * 0x0119c970, int 7300) line 1056 + 30 bytes
stub_put_block(_NET_StreamClass * 0x0119c920, char * 0x00ff9278, long 7300) line
566 + 36 bytes
net_MemCacheWrite(_NET_StreamClass * 0x01095120, char * 0x00ff9278, long 7300)
line 661 + 24 bytes
net_pull_http_data(_ActiveEntry * 0x01196680) line 3003 + 29 bytes
net_ProcessHTTP(_ActiveEntry * 0x01196680) line 3389 + 9 bytes
NET_ProcessNet(PRFileDesc * 0x01151600, int 2) line 3297 + 13 bytes
NET_PollSockets() line 180 + 18 bytes
nsNetlibService::NetPollSocketsCallback(nsITimer * 0x01109310, void *
0x01023e60) line 488
TimerImpl::Fire(unsigned long 11612527) line 321 + 17 bytes
TimerImpl::ProcessTimeouts(unsigned long 11612527) line 199
FireTimeout(void * 0x00000000, unsigned int 275, unsigned int 23402, unsigned
long 11612527) line 103 + 9 bytes
USER32! 77e7128c()
main(int 1, char * * 0x01005210) line 95
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77f1b304()
&#137;
The test that you mentioned works for me. The crash that you got was a Tom
Pixley bug that I think he has subsequently fixed. I'm going to close this one.
Component: Unknown → Networking Library
Verified fixed on 2.1.99 Win32 and Mac OS builds.

However, the test case described (my.netscape.com) crashes Linux reproducibly.

So, I'll simplify the test case and determine whether or not the redirect is in
fact bringing about the crash, and then verify or re-open the bug as appropriate.
Re-opening on Linux (1.29.99 build used, Viewer)

Specifically, on a simplified redirect test case (as provided by Angus, slightly
tweaked for dead URL, at http://www.prometheus-music.com/gecko/bug563.html),
Viewer on Linux pauses for about 5-10 seconds (displaying a blank page), and then
dies.

The console log says:

	handle_size_allocate: top level resize
	Timer::Init() called with bogus value "-1073743640"! Not enabling timer.
QA Contact: 3819
Eli, what kind of redirect is this? Javascript? (I can't see the source).
Assignee: vidur → ramiro
Status: REOPENED → NEW
A Linux-specific problem that relates to timers. I'm happy to help, but this
doesn't look like a JavaScript redirect problem anymore.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
I just tried this on both apr 6 nt and linux builds and it works fine.

marking worksforme.
Status: RESOLVED → VERIFIED
verified. The URL field doesn't update on the re-direct, I believe there is a
separate bug filed on this.
Changing all Networking Library/Browser bugs to Networking-Core component for
Browser.

Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change.  If this happens, I will fix. ;-)
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.
You need to log in before you can comment on or make changes to this bug.