Internet keywords should not be used to resolve relative links

VERIFIED DUPLICATE of bug 34943

Status

()

VERIFIED DUPLICATE of bug 34943
18 years ago
11 years ago

People

(Reporter: bugzilla, Assigned: rpotts)

Tracking

({qawanted})

Trunk
Future
qawanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
If you go to:
http://www.greetkingcards.com/8pickup.html
and press "Pickup Card >>" you're send to http://search.netscape.com.
This should never be the case!

Expected:
Either a 404 error or something like that! Not a weird search page.

Comment 1

18 years ago
if internet keywords are disabled, I'm not sent to Netscape search, I get a
www.<lots of numbers>.com not found error.
(Reporter)

Comment 2

18 years ago
I still think it's *very* wrong to redirect a form submission to a external 
search! External search should only work when the user type words into the 
Location field and pressing Go/Enter...

Comment 3

18 years ago
this looks like a problem with the website, not Mozilla, although I agree that
internet keywords shouldn't be used from links. Perhaps a change of summary to
"Internet keywords should not be used to resolve relative links"?
(Reporter)

Updated

18 years ago
Summary: form submission should never result in search → Internet keywords should not be used to resolve relative links

Comment 4

18 years ago
This is probably a duplicate of bug 34943, although I don't see the Internet 
Keywords feature (or search.netscape.com) mentioned there.

Comment 5

18 years ago
Clicking on links doesn't sound like a search problem, sounds deeper, like in
necko. Although I don't think it's an exact dup of 34943 at quick glance, it's
probably very similar if not an outright dup. Reassigning to gagan.
Assignee: matt → gagan

Comment 6

18 years ago
internet keywords is in webshell->rpotts. 
Rick it seems like to your list of conditions on when the internet keywords kick 
in you might want to add this -- (3) the URL is from the location bar
around 
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsWebShell.cpp#1026
Assignee: gagan → rpotts

Updated

18 years ago
Target Milestone: --- → Future

Comment 7

18 years ago
this could be a potential privacy/security issue too. And so am nominating for 
beta
Keywords: nsbeta1

Comment 8

18 years ago
The URL stated here does not work for me, but I assume that bug's what is also
mentioned in bug 34943 recently (though I think it does belong here but not there):

------- Additional Comments From Marcello Nuccio 2001-03-12 10:39 -------

A link like http:/cgi-bin/man2html?locate+1l (note the single '/' after 'http:')
should be interpreted as relative to the hostname in the URL of the page.

Example: I'm reading
  http://localhost/cgi-bin/man2html/usr/share/man/man1/xargs.1.gz
and I click on the link above; Navigator4.76, lynx and w3m load
  http://localhost/cgi-bin/man2html?locate+1l,
Mozilla (Build ID: 2001031005; Linux) loads
  http://www.cgi-bin.com/man2html?locate+1l
if internet keywords are disabled, and
  http://search.netscape.com/cgi-bin/search?charset=UTF-8&search=cgi-bin
if internet key are enabled.


With this bug, man2html it's unusable with Mozilla, because it generates only
reltive links!

------- Additional Comments From Andreas Otte 2001-03-15 12:11 -------

This kind of relative urls is deprecated with rfc2396 and we decided to no
longer support it. 

-----
If Andreas' comment is right, then the problem I had today with a HTML-based DNS
Adminstration is a WONTFIX :(

Comment 9

17 years ago
Does this still happen, the original link is busted.

Updated

17 years ago
Blocks: 104166

Comment 10

17 years ago
qa to me.
QA Contact: claudius → benc

Comment 11

17 years ago
+qawanted - need testcase and figure out if this needs to be fixed.
Keywords: qawanted

Comment 12

17 years ago
*** Bug 72109 has been marked as a duplicate of this bug. ***

Comment 13

17 years ago

*** This bug has been marked as a duplicate of 34943 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 14

16 years ago
VERIFIED/DUPE
Status: RESOLVED → VERIFIED
Component: Search → Embedding: Docshell
You need to log in before you can comment on or make changes to this bug.