Closed Bug 84450 Opened 23 years ago Closed 23 years ago

Mozilla diverts to a netscape ad page without reason

Categories

(Tech Evangelism Graveyard :: English US, defect, P2)

Product:
Tech Evangelism Graveyard
Component:
English US
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: Dinh-Tuan.Pham, Assigned: bc)

References

(
URL
)

Details

When I search an item from my library site (entering the above ULL then
clicking on "catalogues"), I would get a list of search results containing the
articles which have been found. Then by clicking on this article I would get a
web page of dercription of it. With mozilla, I get instead an ad page of Netscape !

This is _not_ a problem with my library site: I have tested with three other
browsers: Netscape version 4, Konqueror and Opera, all work as expected, except
for mozilla of all versions up to this verion 0.9

THis means that I cannot use mozilla, as I would be denied the service of my
library.

Observations.
1) Mozilla doesn't provide anny error message nor saying why it divert to
Netscape, but launching mozilla on an xterm window, I see this

Error loading URL
http://cgi-bin/Mediatheque.IMAG/catalogues/SFgate?language=french&verbose=0&listenv=table&application=&convert=Mediatheque.IMAG&headline=%28Livre%29%20MULTIPLE%20TIME%20SERIES&waisurl=imag.ouvrages/TEXT/177/1=mersenne.imag.fr%3A210;2=/serveurs/wais/freeWAIS-sf/bases.src.serveur/imag.ouvrages;3=220538%20220715%20/serveurs/wais/freeWAIS-sf/Mediatheque.IMAG/ouvrages/imag.ouvrages.wais;4=mersenne.imag.fr%3A210;5=/serveurs/wais/freeWAIS-sf/bases.src.serveur/imag.ouvrages;6=220538%20220715%20/serveurs/wais/freeWAIS-sf/Mediatheque.IMAG/ouvrages/imag.ouvrages.wais;7=%00;
: 2152398878
Document keyword:cgi-bin loaded successfully

2) Netscape automatically enable the side bar (which I have diabled), which
contains a windows of "Search results" containing strange things completely
unrelated with the item I am seraching in my library site.

3) I am not sure if the site

http://mersenne.imag.fr/Mediatheque.IMAG/

can be assessed from outside the local domain for you to reproduce the bug.
Works for me if I enter the search term "rapport" even so the resulting URL is
ridiculously long. What search terms did you use?
In response to moz@liebesgedichte.siteware.ch

> Works for me if I enter the search term "rapport" even so the resulting URL is
> ridiculously long. What search terms did you use?

I just try the search term "rapport". Yes, I get a list of "rapport",
but then I select the first item, that is

1: (Congres) Bases de donnees : nouvelles perspectives : rapport du groupe BD3

and click on "affiche les notices" and that is when mozilla diverts me to
the ad page of netscape, instead of displaying the "notice" as expected.

Did you continue like me ?

The same thing happens for any search terms, Try for ex, Einstein.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Ok, like this I can confirm the bug.

If you want that someone has a look at it, you shouldn't change
the bug status to Resolved/Fixed. Everyone thinks now
that this bug doesn't occur anymore. :) "Reopen" should do the trick.
(Can't do it for you, I haven't any privileges).

You should also change the component to something else, it's certainly not
chatzilla. I'd say it's "networking: HTTP", but I'm not sure. (Just been
watching and commenting on the incoming bugs.)

Thanks for reporting bugs.
I think the problem is that search result URLs are like this:

          <a href="http:/cgi-bin/...">

This is an uncommon syntax. The normal syntax is:

          <a href="/cgi-bin/...">

Although RFC 1808 seems to allow that strange notation (generic-RL).

http://www.freesoft.org/CIE/RFC/1808/4.htm

This "Generic-RLs" seems to work Ok on MSIE and Nav 4.x but not in Mozilla

As suggested by moz@liebesgedichte.siteware.ch
I reopen this bug (I was unaware that it has been marked fixed) and change
the components to "networking: HTTP" (chatzilla was there by hcance because I
havn't enter anything -- not knowing what it should be)

When I sent this, it was collide with the explanation of
Daniel Mario Vega. This could be the case. But it woukld be difficult to ask
the webmaster of this site to change his setup, especially that it works with
most browsers
Status: RESOLVED → UNCONFIRMED
Component: chatzilla → Networking: HTTP
Resolution: FIXED → ---
reassigning to get it _out_ of rginda's box.
Assignee: rginda → neeti
QA Contact: mozilla → benc
per bug 84456 i'm giving this to evangelism [I was looking for Bug 32966 which 
i was going to dupe this against but...]
Assignee: neeti → bclary
Status: UNCONFIRMED → NEW
Component: Networking: HTTP → Evangelism
Ever confirmed: true
QA Contact: benc → zach
wfm in mozilla 2001-06-06-19 0.9.1/win2k. does anyone have a linux box they can
test with? can't we mark this fixed?
Taking assignment since the site owner is the reporter.

Ok. I clicked on the Catalogues, searched for rapport, selected some of the
results and clicked the Afficher les notices button and was redirected to
netscape search due to the still existing invalid relative url http://cgi-bin/...

This *is* a problem with the library site. The fact that the other browsers do
something non-standard for the invalid relative url is one thing, but what is
the cost of changing the url to /cgi-bin/...?  

Sorry, we are trying to create a standards based browser and we don't try to
emulate bugs in other browsers.  Please fix the url and let us know so we can
check your site again or if you do not wish to fix the url let us know and we
will mark the bug wontfix.

Thanks,
Bob
Status: NEW → ASSIGNED
Well, I will try to persuade the webmaster of this site to change his
syntax.

But I would like to point out that I don't know of any brower other than mozilla which have this behaviour. You call this a bug of other browvers,
but their developpers could call this a "feature" of their browser.

At least you should put a message saying that the syntax is wrong instead of diverting to netscaoe (why netscape ?). This makes me clueless and surely so for an ordinary user. How can I argue that it is a bug of the site when it works for anyone using a brower other than mozilla ? As a matter of fact, I administer serval machines and have switched to mozilla from netsacpe 4.x, but I have to switch back because of an user complaint

Thank for looking into this problem and provining a very fast answers
<rant>
How would you implement such a fallback that would allow users to code relative
URLS as absolute URLS? How could we determine what the user really intended so
that we could give them a syntax error?

Let's use a completely fictional oversimplified example to illustrate the
situation.  Suppose on my local network I have a machine called foo and a
machine named bar.

Then http://foo/ is a valid *absolute* URL for the first machine and http://bar/
is a valid *absolute* URL for the second machine.

Now suppose that on machine foo, there is a web directory named bar.

So, http://foo/bar/ refers to directory bar on machine foo. 

Now suppose we are writing a web page to be hosted on machine foo.  If we
supported the old, broken way of doing things then what does http://bar/ refer
to?  You might say, we could check to see if http://bar/ existed and if not then
look for a local directory. But what if machine bar is down?  Would we
automatically use the http://foo/bar/ directory on machine foo?  You might say
that we should check the local directory first, but then we would never be able
to reference the machine bar.

This is unnecessarily complicated. Any web admin should *know* the difference
beween absolute and relative URLS and we *shouldn't* be asked to support such
simple, trivial, web admin 101 mistakes.

How many other 'common' mistakes should we code work arounds into the browser
for? Should web admins and authors never have to learn that they have been
making errors that have been covered up by idiosyncratic work arounds in earlier
browsers?

Just because invalid practices work on old browsers, does not mean we are
condemned to support them forever. If you want the old way of doing things
supported, then get the standards bodies to incorporate it into the standards.
</rant>

Bob,

That odd syntax was part of a standard. See RFC1808 (
http://www.freesoft.org/CIE/RFC/1808/4.htm )

But then it was corrected in RFC 2396

In bug 22521 there is a long discussion about this problem. Also there is a lot
of bugs duped againts that bug. Perhaps the problem is more frequent than what
we originally thought.
Pham Dinh-Tuan, please excuse me while I remove my foot from my mouth...

Daniel, Thanks for the info. Looks like we may have to approach this in a more
organized fashion.

Changing priority to keep this bug visible and setting OS to all.
OS: Linux → All
Priority: -- → P2
I was discourage when I realize that this "bug" might be flagged WONTFIX.
I like mozilla but if this problem is not fixed either by you or the webmaster
of this site, I woiuld have to use another browser. Nevertheless I appreciate
very much your responsiveness. The webmaster of this site is like a ghost: I
have sent two e-mail *without any response* (may be there is no webmaster,
i.e. the page was created by some one who has left). Anyhow, I suspect that
the people in charge would react only if there are a lot of complaints, but
this is unlikely to happen when the major browsers like MSIE and Netscape still
support this syntaxe.
I have met the webmaster of this site and talk to him in person. He says that he has correct the systax (suppressing the http:/ before cgi-bin), but *the problem remains*

I also have myself looked at the source and search for the occurence of http and cgi-bin, The only place I find them now are

<form METHOD="get" ACTION="http://www-mediatheque.imag.fr/cgi-bin/Mediatheque.IMAG/catalogues/SFgate">

and 
<a HREF="http:http://www-mediatheque.imag.fr/cgi-bin/Mediatheque.IMAG/....

etc

Please be explicit: what is wrong with this source page ? I know nothing
about html and the webmaster doesn't seem to be very good at it either.

Dinh-Tuan, I looked at the page referenced above, and did not find any links
that did not work. 

http://www-mediatheque.imag.fr/cgi-bin/Mediatheque.IMAG/demande.article gave me
an access denied message (I think), "Interdiction d'accès à ce service à partir
de la machine..."

I looked at the link to the Clips page and everything appeared ok there as well
including the relative links.

If you are still having problems, you can give us the exact links on specific
pages which do not work for you and we can take a look, but it appears that the
author is now correctly writing the links and if there are any that do not work
it is probably because he missed them during his earlier edits.
The problem with this site seems to be fixed. The webmaster has corrected
his syntax to conform with the new standard.
great! Dinh-Tuan, thanks a lot for working with us to get this resolved.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
details.
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified
Verified
2002022703/WinXP
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.