4
Replies
I hope you will forgive me if I become overly pedantic. 
According to the official specifications, a URL is composed of 4 parts: <scheme>://<authority><path>?<query>. Perhaps oversimplifying, the <scheme> it the method of retrieving a resource (in this case http) the authority is the network location of the resource, the path is the location of the resource on the network server, and the query is any parameters that need to passed to the resource.
In your case, "https" is the scheme, "SampleDataBaseName.com" is the authority,
"/sfc/#version" is the path and "selectedDocumentId=06950000000Czga" is the query.
The part of the URL that concerns us here is the <path>. This path has three important components, the path separator, the fragment identifier, and the path components. The slash ('/') is the path separator, but the fragment identifier is not just the hash mark but everything following it as well, i.e. "#version". The fragment identifier is used by the browser to find a spot in the returned document, and is not part of the request sent to the server.
In English, your URL is telling a browser: "Find the server 'SampleDataBaseName.com'. Using the 'https' protocol, ask that server for the document 'sfc/', and give it the data 'selectedDocumentId=06950000000Czga' when you do. When the server returns a document, find the spot indicated by 'id="version"' and begin displaying the document from that point on."
The problem with your request, is that a web server couldn't give you the document "sfc/", because with the trailing slash it knows that you're referring to the location of a document on the server, and not one document in particular. What you might get when you request a path without a resource name varies depending on how your web server is set up. Most servers are set up so that when you request "sfc/" it will actually give you "sfc/index.html", and a "404 not Found" error if 'index.html' does not exist in that path. Sometimes the server is configured to give you a directory listing for a bare request. In your case it is probably configured to return the results of a server-side process using CGI, ASP, JSP, or something like that. But it is referencing some specific default resource and not just 'some unspecified document in the "sfc/" sub-directory.'
In this light, RoboHelp is doing the right thing. "/#" really should not appear together because '/' means "what follows is a document or subdirectory" and #version means "find this spot in the document that was returned." What you're essentially saying is "find the 'version' tag in a document that doesn't exist." It might work in a specific instances (based on the default document setting of your web server) or on a specific web server due to its setting, but it's really not a good idea to rely on it.
A better solution would be to find out the name of the resource or document that your web services is actually returning when a root document is requested, and include that in the URL. If the document is generate via a CGI script, that URL might look like
"https://SampleDataBaseName.com/sfc/start.cgi#version?selectedDocumentId=06950000000Czga."
If your using Java Servlets it might be
"https://SampleDataBaseName.com/sfc/start.jsp#version?selectedDocumentId=06950000000Czga."
If I were you I'd find out the name of the default document that is being returned when you ask for "sfc/" and add that to your URL. Not only would that be more consistent with web server standards, it would also make it so that RoboHelp wouldn't keep rewriting your URL in an attempt to make it "safer."
@A25CharacterScreenName....(Nice screen name 
) . Thanks for the detailed answer. That was EXACTLY the type of explaination I was looking for when I was searching the net for a breakdown of sections in a web address.
My problem is 2-fold:
1. RoboHelp is rewriting my URL
2. My URL is generated by the 3rd party website that we use to handle our Knowledgebase and support calls. I suppose it does this because access to the articles I am trying to link to are viewable to clients only, and only after they have logged into the site. So what it does (when I change the URL manually in Robohelp in HTML mode) is re-direct to a login screen, and once entered, pops up the correct article I've linked to.
For now, I can use the work-around and manually change the URL, but if RoboHelp is doing it's part and changing the URL correctly, then I guess the next step would be to take the issue up with our 3rd party site.
Thanks again for the response!
AdChoices