All users were logged out of Bugzilla on October 13th, 2018
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 email@example.com > 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
Last Resolved: 18 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 firstname.lastname@example.org 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
Last Resolved: 18 years ago → 18 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
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.