6700 - No error handling for unsupported protocols

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[cpratt]

build id: 1999051708
platform: windows nt

ok, this is a really lame bug, and it's probably due to something not being
hooked up yet - but if you have access to the netscape internal network, try
going to http://aka using apprunner. result: the DOS window fills up with crud,
viz.:

s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http
s://https://https://https://https://https://https://https://https://https://http

any idea what's wrong?

Comment 1

[dshea]

Yes, it's a case of stuff not being hooked up yet.  But getting attention to
ugly stuff like this seems good to me.

What's happening is this.
Browser is given http://aka, which redirects to the secure https://aka (not just
secure, but client certificate requesting server)

At this point, control should be given over the the crypto module, but the
crypto module isn't present yet, so the browser is barfing.

Now, the thing is.. barfing is bad.  Instead, there should be some manner of
error-handling in the browser when it is given a url/protocol type (in this case
https://) that it doesn't know how to handle.
That might be the bug to enter on this, and it would probably be assigned to the
netlib crew or whoever is handling the 'pluggable protocol' stuff, which I think
is the same guys.  Gagan is probably a good source.

Comment 2

[cpratt]

Well, we're still barfing on this one as of the 1999061409 build under NT. The
URL control is filled with crud, the DOS window is filled with crud, &c.

Comment 3

[Gagan]

Necko landing...

Comment 4

[James Everingham]

I'm moving this to target M9, Necko will be enabled somewhere during late M8 or
early M9.  We will need to get on this and it cannot be postponed past the M9
milestone.

Comment 5

[leger]

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. ;-)

Comment 6

[Gagan]

Fixed with Necko.

Comment 7

[cpratt]

http://aka is now crashing badly - but if I remember correctly, this problem has
now been fixed. Verifying.

Comment 8

[leger]

Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.