Bug 136790 - hosts should be tested with resolv.conf domains before doing keyword lookup
hosts should be tested with resolv.conf domains before doing keyword lookup
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: epiphany (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-22 08:33 EDT by Need Real Name
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-15 07:07:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2004-10-22 08:33:17 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020 Epiphany/1.4.4

Description of problem:
Epiphany interprets hostnames such as "box", "bigmetal" as keywords,
and searches Google for them.

Instead they should be treated as hostnames.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
x

Additional info:
Comment 1 Need Real Name 2004-10-22 08:57:52 EDT
Also, http://hostname and http://hostname/ are treated as search
engine keywords.
Comment 2 Sitsofe Wheeler 2004-11-27 18:09:30 EST
This occurs because about:config keyword.enabled is true (if the
hostname can't be resolved that option make the typed words be used as
a google search). Setting it to false turns off the behaviour.
Comment 3 Need Real Name 2004-11-28 05:58:01 EST
The bug is that if I type a hostname in, it should go to the website
on that host.
It shouldn't search Google.
Comment 4 Sitsofe Wheeler 2004-11-28 14:44:15 EST
Does it go to the right url if you turn keyword lookups off?
Comment 5 Need Real Name 2004-11-29 04:52:39 EST
No.
Comment 6 Sitsofe Wheeler 2004-11-29 08:02:01 EST
No, it didn't go because the computer blew up? No, it went to yahoo
instead of google this time?

What happened? The suspense is killing me : )
Comment 7 Sitsofe Wheeler 2006-05-26 11:32:50 EDT
No answer @nodata.co.uk in over a year. Perhaps this bug should be closed?
Comment 8 Need Real Name 2006-05-26 12:30:41 EDT
What information do you need from me?

Yiz asked me if it goes to the right url if you turn keyword lookups off, and I
said that it didn't.
Comment 9 Sitsofe Wheeler 2006-05-27 03:42:43 EDT
What does the browser actually do (e.g. what address does it go to or what does
it say) when keyword.enabled is set to false? Does it still go to Google like
your bug said it did?
Comment 10 Need Real Name 2006-05-27 05:18:35 EDT
Re-setting keyword.enabled back to false does workaround the problem, but that's
not a solution.

The bug is that hostnames are intepreted as search keywords.

If I don't enter a fqdn, a check should be made to see if the host exists
("host" on its own is a valid way of writing a hostname), and only if it doesn't
should a keyword search be launches.

e.g. In this example keyword.enabled=true
$ ping apache1
(I get a response from apache1.mydomain)
$ lynx apache1
(I get a response from apache1.mydomain)
$ epiphany apache1
(I get a google search for apache1)

This is a bug - apache1 is a valid hostname, it should have followed the entry
in my resolv.conf file first, and resolved it to apache1.mydomain

If apache1.mydomain didn't exist, then it could run the google search.
Comment 11 Sitsofe Wheeler 2006-05-31 17:28:42 EDT
It might we wise to retitle this bug to something like this:
hosts should be tested with resolv.conf domains before doing keyword lookup
Comment 12 Matěj Cepl 2007-04-23 11:13:49 EDT
Reporter, could you please it reproduce this with current release of the
package. I have here epiphany-2.16.3-4.fc6 and it works for me.
Comment 13 Matěj Cepl 2007-05-15 07:07:24 EDT
No reply from reporter, closing as INSUFFICIENT_DATA.

Note You need to log in before you can comment on or make changes to this bug.