Internet keywords should not be used to resolve relative links

VERIFIED DUPLICATE of bug 34943

Status

()

Core
Document Navigation
VERIFIED DUPLICATE of bug 34943
17 years ago
10 years ago

People

(Reporter: Henrik Gemal, Assigned: rpotts (gone))

Tracking

({qawanted})

Trunk
Future
qawanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 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

17 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

17 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

17 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

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

Comment 4

17 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

17 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

17 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

17 years ago
Target Milestone: --- → Future

Comment 7

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

Comment 8

17 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

16 years ago
Blocks: 104166

Comment 10

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

Comment 11

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

Comment 12

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

Comment 13

16 years ago

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

Comment 14

15 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.