Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001080graphvizWebdotpublic2006-03-13 05:262011-04-28 04:03
ReporterLambert Fabian 
Assigned Toellson 
PrioritynormalSeveritymajorReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOS*-*-OS Version
Summary0001080: web dot bug with https URL
Description



It seems that, when parsing URL string,
the web dot cgi-bin take only into account "http://..." [^] URL and not
"https://" [^] ones.
Additional Information

[fabian]
1. If I try to put an "https://%s" [^] links in a node of the graph (URL argument), webdot is parsing badly the URL (see the dot file in attachment (AMI_3_2_0.dot)
And a consequence is that links on the graph are broken (AMI_3_2_0.dot.dot.map).
It is because webdot parse only URL starting with http://%s [^] and not https://%s [^] for the links. So if I put https://%s [^] links, it considers that it is not a http://%s [^] links and add the "default" server string to the URL.
I obtain then something like http://myserver:8080/https://.... [^] which is bad.

2.A consequence of this is that if I try to put some links starting with http://%s [^] in order to have good links, and then, if I create a graph on a an https://%s [^] URL page:
If I click on a link from the graph, I will "exit" the https mode which is not what I want.

[north] I think he is saying that webdot (in TCL) does not know how to pull (download) graphs that
have a URL that begins with https not http. Or, possibly, the name mangling that we do to
get clickable nodes is rewriting \N with a string that begins http, not https. I'm not
sure, because the bug report was a little vague. Maybe Fabian can comment further?

[fabian]

I have an HTML page at URL https://myserver.com [^] where I put a webdot graph.
The webdot graph contains nodes and arrows. In each nodes, I put a web link (which is defined by the "URL" parameter in webdot language).
My problem is that if I define a node's web link as "https://anotherserver.com", [^] then webdot doesn't read correctly this link.

I solved partially the problem in the code (line 293)

INITIAL CODE
<CD>
###########################################################################
# webdot::make_absolute_url
#
# support routine for webdot::fix_graph_urls
#
# returns: absolute_url
#
proc webdot::make_absolute_url {serverport dirname ref name} {
   regsub -all {\\N} $ref $name ref
* if {[scan $ref {http://%s} [^] .] != 1} {*
       if {[string first / $ref] == 0} {
           set ref http://$serverport$ref [^]
       } {
           set ref http://$serverport$dirname/$ref [^]
       }
   }
   return $ref
}
</CD>

As you see at the bold line, we go in the "if" only if we don't find a string ref beginning by "http://", [^] else we return the "$ref".
That is why, if $ref="https://anotherserver.com", [^] the function return something like http://myserver.com:8080/https://anotherserver.com [^] which is bad;
While if $ref="http://anotherserver.com", [^] the function http://anotherserver.com [^] which is what I want.

That is why I changed the code as below :
PATCHED CODE

<CD>
###########################################################################
# webdot::make_absolute_url
#
# support routine for webdot::fix_graph_urls
#
# returns: absolute_url
#
proc webdot::make_absolute_url {serverport dirname ref name} {
   regsub -all {\\N} $ref $name ref
  * if {[scan $ref {http%s} .] != 1} {*
       if {[string first / $ref] == 0} {
           set ref http://$serverport$ref [^]
       } {
           set ref http://$serverport$dirname/$ref [^]
       }
   }
   return $ref
}
</CD>

It works, but there is several line in the code where problems like this are susceptible to appear.

[ellson]
An alternative change would be to use regexp:
<CD>
   if {[regexp {https?://.+} $ref] !=1} {
</CD>

It will still fail for other protocols, e.g. ftp://


I need to think more about this. https: (or ftp:) cannot be used for all URLS
processed by webdot. Specifically, any URL for which the webdot cgi is
the client can't be https because the client code in webdot has no support for anything but http.
(e.g. .dot files from an upstream server.)

I'm going to have to separate out those cases where https is allowed from those where it is not.

At least your patch works for you for now.

[fabian]
In my application, I can view pages by two different ways, http or https.
The only inconvenience of the patch is that if I display a page from an http URL, as my graph links are now "https", I switch from "http" to "https" each time I click on them.
It is not really a problem but it is not very nice.

What will be nice would be to detect if the graph is called from an http or https page, and then to "correct" the graph links URL consequently.
I don't know if it is possible ? For now, as you said client can't be https because the client code in webdot has no support for anything but http.
Maybe a solution is to implement the https usecase for webdot so that if we start in https mode we stay in https and the same for http ?

TagsNo tags attached.
AUXILLARY-FILES
DATE-FIXED
FIX-COMMENT
FORMER-ID902
INPUT-FILEhttp://www.graphviz.org/bugs/b902.doc [^]
OUTPUT-FILE
STATUS-COMMENT*
VERSION     2.8
Attached Files

- Relationships

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2011-04-28 04:03 user1 New Issue
2011-04-28 04:03 user1 Assigned To => user695


MantisBT 1.2.5[^]
Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker