Forum Moderators: open
The reason for this is that I don't want to cloak my primary domain for the risk of it being banned in the search engines.
Would this model of cloaking and redirection work?
It's what I read elsewhere, never cloak your primary domain if you fear getting banned, so I don't see how to get the traffic to the primary domain without redirection.
Links would work, but redirection would ensure 100% of SE traffic would go to the primary domain.
There are ways to "redirect" without "redirecting". What I mean, is that you can have a server-side script make a HTTP request to your primary domain, and serve up the results under the original cloaked URL. This is transparent to the end user. It isn't technically a "redirect", and no redirect header is sent.
Dan
That sounds really impressive, can you send me via sticky mail a name of a script that will create these "redirections"
#!/usr/bin/perl -w
$url="http://www.somedomain.com/index.html";
use LWP::Simple;
$HTML=get $url;
print $HTML;
exit;
Post #6 in this thread might also be interesting, don't want to repost it: [webmasterworld.com...]
/claus
Better than stick mail, here's a simple perl script:
#!/usr/bin/perl -w
$url="http://www.somedomain.com/index.html";
use LWP::Simple;
$HTML=get $url;
print $HTML;
exit;
Alright, sorry to intrude into this conversation here, but I just had a quick question relating to this...
I created a file in my cgi bin entitled redirect.pl and threw this into it.
I then created a shtml doc with nothing in between the body tags but <!--#include virtual="cgi-bin/redirect.pl" -->
All I'm getting is [an error occurred while processing this directive]!
What am i doing wrong? I apoligize in advance if it's blindingly obvious to all others... I'm kinda new at this!
Thanks!
Try this, it sometimes does the trick
<!--#exec cgi="cgi-bin/redirect.pl" -->
Btw. you could also just call the script "index.pl" or "index.cgi" if your server supports such file types as index files.
>> nothing in between the body tags but
You'll get double body tags then, as the destination doc also has them i suppose.
/claus
I am still having trouble though! I tried what you suggested with the execute vs the include, that seems to stop me from getting the error message. I then took your advice and changed it into a .cgi file and named it index, which my host does infact allow... and got a 500 / Internal Server Error message!
Which led me to believe that there is a problem with my implimentation of the original code. All I did was copy and paste it into a text file (now) named index.cgi, of course changing the "somedomain" to my domain, and uploaded it. The path to perl is correct and all of that. Not sure if this matters, but I also chmodded it to both 755 and 777 and tested both. No go! Any idea what i mistyped or anything?
Thanks, DS
#!/usr/bin/perl -w
Telnet to the server and, at the command prompt, type "whereis perl" to determine the correct path to Perl on your server.
I wish it were that easy though! That is infact the path to perl at my host, or at least they tell me it is. I can use either #!/usr/bin/perl or #!/usr/local/bin/perl. So that's not my problem, per se...
I also verified that I have support for LWP::Simple, which I do, and tried to track down what the -w stands for. As far as I can tell it is a diagnostic tool that produces some sort of results somewhere, although I havn't been able to find them (Like I said, I'm kinda new at this advanced sorta stuff!). Probably real simple, but dumb old me can't find them!
Thanks agian though!
DS
print "Content-type: text/html\n\n";- it's a pure guess, but it's usually needed when writing to a web page. Also, you might want to put this just under the shebang until you get it to work, it will (try to) tell you where the error is:
use CGI::Carp qw(carpout fatalsToBrowser);But be sure to remove it again when it all works.
- so try this:
-----------------------
#!/usr/bin/perl
use CGI::Carp qw(carpout fatalsToBrowser);
use LWP::Simple;
$url="http://www.somedomain.com/index.html";
$HTML=get $url;
print "Content-type: text/html\n\n";
print $HTML;
exit;/claus
Your 'Just a Guess' of adding the
print "Content-type: text/html\n\n";
was dead on! After doing so, it worked perfectly!
Thanks for all your help... Much appreciated!
DS
Sorry about that, i was in a hurry to get out of the door when you posted, so i did not post until i came back :)
/claus
<?
include("http://www.somedomain.com/index.html");
?>
<br />
<b>Warning</b>: main(): stream does not support seeking in <b>/home/sitename/public_html/testing/something.php</b> on line <b>2</b><br />
Before anything else on the page... Do I need to add something else?
Claus... Wouldn't really have made a difference at all as that the cable died as I was coming back here to check out the thread! Basicly, I wouldn't even have known about it even if you had posted it 30 seconds after my last post... Irregardless, I was estatic to finally have it working and honestly really appreciate your help!
Thanks agian, DS
I'm so embarrassed!
Dan
hehe
I'll post code if anybody wants me to.
I've seen (on a PHP forum) that the cause of this error is that you use it with "http:". The solution, apparently, is to include a small at-sign first, like this:
<?
@include("http://www.example.com/index.html");
?>I don't really use php myself, so i'm not able to confirm this or explain why.
I suppose that the "main stream" is what gets sent to the browser form the server and that php is not able to perform operations (apart from "pass on/display") on content hosted elsewhere unless it's imported in another way. If the @ sign is an array, then it makes some sense somehow, but as i said i really don't know, i guess that it's not but rather a prefix for "external" or something.
/claus
added: volatilegx, i know it, i do this myself all the time, just write some code straight from memory or outside context. Your code did do the job asked for - the header was just a detail. It might as well have been that some module wasn't available or whatever. There's just so many things you can do that it happens all the time (to me at least, it does : )
May also want to try
readfile()include()
use HTTP::Request::Common qw(POST);
use LWP::UserAgent;
$ua = LWP::UserAgent->new;
$uatopasson = $ENV{"HTTP_USER_AGENT"}; # or make one up
$referertopasson = $ENV{"HTTP_REFERER"}; # or make one up
$ua->agent($uatopasson);
$req->header('referer' => $referertopasson);
my $req = POST 'http://www.somedomain.com/cgi-bin/cgiscript.cgi',
[ field1 => 'value1',
field2 => 'value2' ];
$response = $ua->request($req)->as_string; # process $response however you like...
The best part about the snippet above is that you don't have to URL-encode the field name/value pair strings.
[edited by: volatilegx at 4:15 pm (utc) on Aug. 25, 2003]
Unfortunately, with programming, "it's all in the details".
I hate it when a script I'm working on errors out because I forgot the header. :)
