As I understand it, search engines try to avoid indexing dynamic content. It's apt to not be the same on retrieval. They can't tell, though, if the URL for access is disguised through any of the server's aliasing or rewriting techniques. That done, it's all html to them.
After Compline,
Zaxo
| [reply] |
We use url rewritting technic expressly to get search engines to not reject the sites we build. Once that is done then the whole issue of search engine rank comes into play and thats a separate discussion.
| [reply] |
If necessary, you can pass parameters to a CGI script so that the URL looks "normal". For example:
http://www.mysite.com/myscript/param/and/more/params
where myscript is your script and everything following it is a sequence of parameters.
The trick is that everything beyond the script name gets stored in an environment variable called PATH_INFO. So you could then do something like this:
my ($this, $that, $the, $other) = split '/',$ENV{PATH_INFO};
Just because it looks like a normal path to the user (and presumably to search engines) doesn't mean your code has to interpret it as such.
I should mention that, while I know this technique works on Apache, I'm not certain it's a universal capability. | [reply]
[d/l]
[select] |
I honestly dont get wut u mean here how is myscript a script its a folder????
| [reply] |
Think of the URL less literally as a directory path, and more as a string that gets passed to the Web server to tell it where to look for a file to serve.
Let's say you have a server whose docroot is at ~myname/httpd. This server is visible at the URL http://www.mysite.com.
Now any file you put into ~myname/httpd, say ~myname/httpd/contact_me.html, is available through the Web server -- in this case as http://www.mysite.com/contact_me.html.
That file doesn't have to be an HTML document; it could also be a script. Save a simple CGI script in the docroot as test.pl and you can now run it by visiting http://www.mysite.com/test.pl. (Maybe; see footnote below.)
You can append even more information to the URL, like http://www.mysite.com/test.pl/12345, and this will still run test.pl with 12345 in $ENV{PATH_INFO}.
Is any of this really necessary for your particular application? I don't really have enough information to say. But it is an alternative to the question-mark way of passing CGI params.
Footnote: Depending on your server configuration, you might not actually be able to execute arbitrarily-named programs from arbitrary directories. So you might actually have to do something like http://www.mysite.com/cgi-bin/myprog.cgi/more/params/go/here.
| [reply] |
actuall, I wanted too do this
http://webewebin.com/?source=/Programs_and_Scripts/Perl/Advertisements/
..but I couldnt do that if I had c++ cause of the pluses will mess it up | [reply] |
