Closed Bug 56426 Opened 24 years ago Closed 22 years ago

Links not working in pages build into Cisco devices

Categories

(Tech Evangelism Graveyard :: Polish, defect, P3)

Product:
Tech Evangelism Graveyard
Component:
Polish
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: M.Hankus, Assigned: chrisc)

References

(
URL
)

Details

Hello.

  There is a problem with cisco devices (rotuers, switches etc.) This devices can
be managed via HTTP, but their homepage is very ugly (it probably does not
validate as HTML), but there is a lot of such devices, and you can't change
their start pages. So maybe there is some way to make it work under Mozilla (it
works under Netscape 4.75 and earlier). If you want to see how such homepage
looks like check above URL, and press "Show interfaces" link (in href there is
no host information, href looks like href=/exec/sadasd.cgi). Of course it is not
real home page, so links will not work, it is just an example.
I don't understand what the problem is here.
I go to the url and the page displays.
Clicking on 'Show Interfaces' goes to a url that doesn't exist, same as with
Netscape 4.
The only issue I can find is that the url for the 'Show Interfaces' link is
http:/exec/show/interfaces/CR
This should be http://exec/show/interfaces/CR
In the status bar Mozilla displays http:/exec/show/interfaces/CR, whereas
Netscape displays http://exec/show/interfaces/CR
However, both Netscape 4 and Mozilla go to http://exec/show/interfaces/CR when
the link is clicked on.

No !!!
   Here is fragment of my access.log from my squid cache.
  When i hit the link with Netscape i got

GET http://www.ce3.pl/exec/show/interfaces/CR - DIRECT/www.ce3.pl text/html

  But when i click with Mozilla

GET http://exec/show/interfaces/CR - DIRECT/exec -

You  see !! Netscape added hostname to the URL, Mozilla did not, and squid does
not know where to look for the data.


Communicator, IE and Java all agree that if the protocol is the same then it may
be redundantly specified and the link may be a relative link. Thus, given a base
of http://host/dir/file.ext the following URLs are valid self-referencing links:

file.ext
/dir/file.ext
//host/dir/file.ext
http:file.ext
http:/dir/file.ext
http://host/dir/file.ext

According to RFC1808 this was a loophole in prior specifications of partial URLs.
So http:/exec/show/interfaces/CR is a valid link, but Mozilla treats "exec" as 
hostname not as directory.  
I added one more test. Please visit the link below, and click the link with
Netscape, and with Mozilla. Netscape opens a new document, Mozilla says that
there is error. (My build is 2000101520)

http://www.ce3.pl/~mhankus/moz2/c.html

Yup.  Confirmed on Mac 10-11-08.  Seems like funky behavior.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reassigning to Networking component.
Assignee: clayton → gagan
Component: HTML Element → Networking
QA Contact: lorca → tever
Target Milestone: --- → Future
Duplicate of a wontfix bug

*** This bug has been marked as a duplicate of 32966 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
verified dupe of wontfix bug 32966: "http:/ (one slash) treated as http://
rather than /"
see also similar wontfix bug 22251: "Relative URLs with scheme (e.g.,
http:page.html) not loading - treated as absolute"
Status: RESOLVED → VERIFIED
Reporter: I assume you are the mentainer of the site mentioned in this bug
report, the href="http:/exec/show/interfaces/CR" should be
href="/exec/show/interfaces/CR"
and the other links also need to be changed this way. Please correct the page.


I'm not a maintainter, it was just an example what is inside every CISCO device
(i manage a lot of them, so I have a big problem with doing it with mozilla).


moving to evangelism after speaking w/ a friend @cisco :)
Assignee: gagan → chrisc
Status: VERIFIED → NEW
Component: Networking → Evangelism
QA Contact: tever → timeless
os: IOS. platform probably mips.
OS: Windows 98 → other
Hardware: PC → SGI
Resolution: DUPLICATE → ---
Target Milestone: Future → ---
*** Bug 82068 has been marked as a duplicate of this bug. ***
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
This bug is known at Cisco, see:
http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdu69702
and the dupes:
http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdv84340
http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdu70315
(you'll need a CCO access, i.e. be a Cisco client/partner, etc. to actually see
this defect).
However, it's now solved when upgrading IOS to a recent version for certain
IOS-based Cisco devices, not all yet. This needs to be verified though but it
should be ok.
NB: I work at Cisco.
OS: other → All
Hardware: SGI → All
Mirek, if you've upgraded IOS, can you check on this again?
Now it works. They fixed it.
Marking FIXED as per reporter comments and Cisco bug reports: comment #16.
Status: NEW → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → FIXED
Verified, as bug 22251 is now checked in, allowing http:/ style URLs.
Status: RESOLVED → VERIFIED
tech evang june 2003 reorg
Component: US General → Polish
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.