Re: [slightly OT] Problem with cookies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 8:05 PM -0700 4/7/00, Randal L. Schwartz wrote: Kee Well, the good news is that if they don't support Host:, they Kee certainly aren't going to support cookies! Why? Those are orthogonal features. HTTP/1.0 did not require "host:". And certainly, browsers that handled HTTP/1.0 had cookies. I guess I mis-remembered. I thought cookie support came after 1.1. - -- Kee Hinckley - Somewhere Consulting Group - Cyberspace Architects(rm) I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.2 for non-commercial use http://www.pgp.com iQA/AwUBOO9ihSZsPfdw+r2CEQJR6ACgkeu3CQy39slkB7+Pg6rgcBg7M8AAn0Iv TLOuIwPOrzqyDAErK0N16ye0 =plvO -END PGP SIGNATURE-
RE: [slightly OT] Problem with cookies
Now we are moving even further off topic but I've got to put my $0.02 in here. :) So what if older browsers might get stuck in an infinite loop. GOOD! That's what they deserve for not upgrading their browser. I've already got to develop DOWN to version 3.0 of the browsers. Now I have to worry about them not sending the host: header? H*LL no! What percentage of people are still browsing with browsers that don't send that header? According to the figures that I've seen no more than 2%. Oh no, I'm missing out on 2% of the market. :) I'd rather have 98% of the market and be able to use some important features rather than really dummy things down. This is all my personal opinion but at some point, we all as developers have to look at what we are doing and decide exactly how far back we are going to be compatible with browsers. My personal opinion is that I go back only 2 versions. If someone is still (again IMHO) stupid enough to continue to use an old version of a browser when they can download the latest versions, then whatever they get, they deserve. -- Jeff Stuart [EMAIL PROTECTED] -Original Message- From: Jim Winstead [mailto:[EMAIL PROTECTED]] Sent: Friday, April 07, 2000 12:08 PM To: [EMAIL PROTECTED] Subject: Re: [slightly OT] Problem with cookies On Apr 07, Randal L. Schwartz wrote: I think this also suffers from placing the burden on the client. The [R] there with an external rewrite means that the client will get redirected if it doesn't tell you the right "Host:" header. But HTTP/1.0 and older browsers (and some spiders) will NOT tell you that header, so you get in an infinite loop. The solution is that you must allow for an unspoken "Host:" header to fall through to a generic v-host. An important point is that although "Host:" wasn't required until HTTP/1.1, all of the common browsers have sent it with 1.0 requests for some time. This includes Netscape since version 2.0 and Internet Explorer since 3.0. Most browsers released since 1996 have sent it. I strongly suspect that all of the reputable search engine spiders send it as well. (That doesn't mean you shouldn't be careful and structure it so that you don't send Host-less requests into a redirect loop, I just want to make sure people know the situation isn't quite as dire as Randal may have made it sound. There are a large number of people relying on browsers sending the Host header to great effect.) Jim
RE: [slightly OT] Problem with cookies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 4:03 PM -0400 4/8/00, Jeff Stuart wrote: GOOD! That's what they deserve for not upgrading their browser. I've Clearly you've become confused. The owner of the browser is the customer, you are serving them, not the other way around. If you don't like that, you're in the wrong business. Find something that doesn't involve software. Just this Christmas I installed Netscape 2 on someone's machine. 2? What would *you* install on an 8MB 68K Mac for someone who can barely afford the monthly access fees for using the internet? If you want to followup, don't cc the list. - -- Kee Hinckley - Somewhere Consulting Group - Cyberspace Architects(rm) I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.2 for non-commercial use http://www.pgp.com iQA/AwUBOO+ZuiZsPfdw+r2CEQK1UwCdG8FM7uRy8NgSEB4stnTHeegI13oAoKIh Ft3/euj1jPY71I7laJaBU/6x =Ue8l -END PGP SIGNATURE-
Re: [slightly OT] Problem with cookies
"Jeff" == Jeff Stuart [EMAIL PROTECTED] writes: Jeff Now we are moving even further off topic but I've got to put my Jeff $0.02 in here. :) So what if older browsers might get stuck in Jeff an infinite loop. GOOD! That's what they deserve for not Jeff upgrading their browser. I've already got to develop DOWN to Jeff version 3.0 of the browsers. Now I have to worry about them not Jeff sending the host: header? H*LL no! What percentage of people Jeff are still browsing with browsers that don't send that header? What if one of those browsers were a web indexer for AltaVista or Infoseek? Do you really want that many people to not find out about your site? It's not about browsers, sir. It's about the web-dexers. If you aren't writing for that market, you are missing a HUGE set of possible visitors. Never piss off a spider. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: [slightly OT] Problem with cookies
"Kee" == Kee Hinckley [EMAIL PROTECTED] writes: Why? Those are orthogonal features. HTTP/1.0 did not require "host:". And certainly, browsers that handled HTTP/1.0 had cookies. Kee I guess I mis-remembered. I thought cookie support came after 1.1. It wouldn't matter if it came *after* or *before*, unless you think there's only one timeline relevant. There are many timelines. There are "browsers" being written today that don't support "host:". See my other comment about "web-dexers". -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: [slightly OT] Problem with cookies
"Rusty" == Rusty Foster [EMAIL PROTECTED] writes: Rusty NameVirtualHost 216.181.35.174 # IP of www.kuro5hin.org Rusty # Redirect all hostless requests to www VHost Rusty VirtualHost 216.181.35.174 Rusty ServerName kuro5hin.org Rusty Redirect permanent / http://www.kuro5hin.org/ Rusty /VirtualHost Rusty # Proper URI for www.kuro5hin.org Rusty VirtualHost 216.181.35.174 Rusty ServerName www.kuro5hin.org Rusty ...etc... Rusty /VirtualHost Rusty This way, people who come in to http://kuro5hin.org/ get redirected Rusty right off the bat, and so far this seems to have solved the problem. Except that this requires HTTP/1.1. Anyone that doesn't send the "host:" header goes into a permanent redirect loop. So the "problems" you're not seeing are probably from the people out there that can't get to your site to report the problems. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: [slightly OT] Problem with cookies
"Drew" == Drew Taylor [EMAIL PROTECTED] writes: Drew The dual VirtualHost configuration is exactly the solution I will take! It Drew will also apply it to the main domain as well - thinkstock.com, .org, and Drew .net. That will solve my problem, as well as any future ones, and I can Drew just be done with this stupid cookie problem! You just made my night better Drew (and my morning too)! But please see my followup before you implement it. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: [slightly OT] Problem with cookies
Randal, Thanks for the tip. So my question is: what is the best solution? I want to redirect http://cloudstock.com/ to http://www.cloudstock.com/. Should I take out the permanent in the Redirect directive? Should the www entry come first? Do I need to get another IP address? Or do you know what bit of cookie magic I need to get the cookies to stick to cloudstock.com? I have implemented it for now anyway. Once I figure something else out or start getting complaints I'll change it. "Randal L. Schwartz" wrote: "Rusty" == Rusty Foster [EMAIL PROTECTED] writes: Rusty NameVirtualHost 216.181.35.174 # IP of www.kuro5hin.org Rusty # Redirect all hostless requests to www VHost Rusty VirtualHost 216.181.35.174 Rusty ServerName kuro5hin.org Rusty Redirect permanent / http://www.kuro5hin.org/ Rusty /VirtualHost Rusty # Proper URI for www.kuro5hin.org Rusty VirtualHost 216.181.35.174 Rusty ServerName www.kuro5hin.org Rusty ...etc... Rusty /VirtualHost Rusty This way, people who come in to http://kuro5hin.org/ get redirected Rusty right off the bat, and so far this seems to have solved the problem. Except that this requires HTTP/1.1. Anyone that doesn't send the "host:" header goes into a permanent redirect loop. So the "problems" you're not seeing are probably from the people out there that can't get to your site to report the problems. :) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704.370.0550 http://www.vialogix.com
Re: [slightly OT] Problem with cookies
On Fri, 7 Apr 2000, Drew Taylor wrote:
Randal,
Thanks for the tip. So my question is: what is the best solution? I want
to redirect http://cloudstock.com/ to http://www.cloudstock.com/.
Should I take out the permanent in the Redirect directive? Should the
www entry come first? Do I need to get another IP address?
i'm just learning about the beautiful magic of the RewriteEngine. could
this be a good solution for you? in order to make sure cookies always
work properly on http://mp3.boston.com which is aliased as
http://music.boston.com, we use the following RewriteRule:
RewriteEngine on
RewriteCond %{HTTP_HOST} !^mp3\.boston\.com [NC]
RewriteRule ^/(.*) http://mp3.boston.com/$1 [L,R]
this ensures that every request gets fixed as "mp3.boston.com" no matter
how it comes to us. i think this is what you want.
see here for more documentation:
http://www.apache.org/docs-1.2/mod/mod_rewrite.html
ky
Re: [slightly OT] Problem with cookies
On Apr 07, Randal L. Schwartz wrote: I think this also suffers from placing the burden on the client. The [R] there with an external rewrite means that the client will get redirected if it doesn't tell you the right "Host:" header. But HTTP/1.0 and older browsers (and some spiders) will NOT tell you that header, so you get in an infinite loop. The solution is that you must allow for an unspoken "Host:" header to fall through to a generic v-host. An important point is that although "Host:" wasn't required until HTTP/1.1, all of the common browsers have sent it with 1.0 requests for some time. This includes Netscape since version 2.0 and Internet Explorer since 3.0. Most browsers released since 1996 have sent it. I strongly suspect that all of the reputable search engine spiders send it as well. (That doesn't mean you shouldn't be careful and structure it so that you don't send Host-less requests into a redirect loop, I just want to make sure people know the situation isn't quite as dire as Randal may have made it sound. There are a large number of people relying on browsers sending the Host header to great effect.) Jim
Re: [slightly OT] Problem with cookies
Jim Winstead wrote: An important point is that although "Host:" wasn't required until HTTP/1.1, all of the common browsers have sent it with 1.0 requests for some time. Yes, but I've had problems with corporate proxy servers that don't send it. - Perrin
Re: [slightly OT] Problem with cookies
Oops. Meant to send this to the list. :-) Bill Moseley wrote: At 07:29 PM 04/06/00 -0400, Rusty Foster wrote: What I ended up doing was targeting cookies at a host (i.e. domain=www.kuro5hin.org), and setting up VirtualHost sections as follows: NameVirtualHost 216.181.35.174 # IP of www.kuro5hin.org # Redirect all hostless requests to www VHost VirtualHost 216.181.35.174 ServerName kuro5hin.org Redirect permanent / http://www.kuro5hin.org/ /VirtualHost # Proper URI for www.kuro5hin.org VirtualHost 216.181.35.174 ServerName www.kuro5hin.org ...etc... /VirtualHost Why not reverse the order of these virtual host sections so people without a Host: host go to the www.huro5hin.org virtual host? Their URL will read wrong, but not much you can do about that. That's how it was originally, and they went to the right VHost, *BUT* you recall that the original problem was cookies. I had to target my cookies to 'www.kuro5hin.org', because there are other virtual hosts in the same domain that get a different cookie with the same name. They need to be distinguished by hostname, and the browser won't send a cookie targeted at 'www.kuro5hin.org' to 'kuro5hin.org'. Hence, the URL has to read right, for everything to work. --R Bill Moseley mailto:[EMAIL PROTECTED] -- === | Rusty Foster | "You can never entirely stop being what | | [EMAIL PROTECTED]| you once were. That's why it's important | |[EMAIL PROTECTED] | to be the right person today, and not put | | http://www.kuro5hin.org | it off till tomorrow."-Larry Wall | ===
Re: [slightly OT] Problem with cookies
I got this from the URL I mentioned in a previous post. I have modified
it a bit to what looks like a solution. I guessing that the condition
are met w/ no Host: header or a Host: cloudstock.com header. It looks
like it would solve the no Host: header problem as well as do my primary
task of sending everyone to www.cloudstock.com. Can someone w/
mod_rewrite experience tell me if it suffices?
Boy, this thread has gotten REALLY off topic. I apologize to the list
for that, but I do appreciate all the posts. :-)
RewriteCond %{HTTP_HOST} !^domain\.name [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/(.*) http://www.domain.name/$1 [L,R]
Jim Winstead wrote:
On Apr 07, Randal L. Schwartz wrote:
I think this also suffers from placing the burden on the client. The
[R] there with an external rewrite means that the client will get
redirected if it doesn't tell you the right "Host:" header. But
HTTP/1.0 and older browsers (and some spiders) will NOT tell you that
header, so you get in an infinite loop.
The solution is that you must allow for an unspoken "Host:" header to
fall through to a generic v-host.
An important point is that although "Host:" wasn't required until
HTTP/1.1, all of the common browsers have sent it with 1.0 requests
for some time. This includes Netscape since version 2.0 and Internet
Explorer since 3.0. Most browsers released since 1996 have sent
it. I strongly suspect that all of the reputable search engine
spiders send it as well.
(That doesn't mean you shouldn't be careful and structure it so
that you don't send Host-less requests into a redirect loop, I just
want to make sure people know the situation isn't quite as dire as
Randal may have made it sound. There are a large number of people
relying on browsers sending the Host header to great effect.)
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704.370.0550
http://www.vialogix.com
Re: [slightly OT] Problem with cookies
At 1:01 PM -0400 4/7/00, Rusty Foster wrote: Oops. Meant to send this to the list. :-) you recall that the original problem was cookies. I had to target my cookies to 'www.kuro5hin.org', because there are other virtual hosts in the same domain that get a different cookie with the same name. They need to be distinguished by hostname, and the browser won't send a cookie targeted at 'www.kuro5hin.org' to 'kuro5hin.org'. Hence, the URL has to read right, for everything to work. Well, the good news is that if they don't support Host:, they certainly aren't going to support cookies! -- Kee Hinckley - Somewhere Consulting Group - Cyberspace Architects(rm) I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Re: [slightly OT] Problem with cookies
On 7 Apr 2000, Randal L. Schwartz wrote: Rusty NameVirtualHost 216.181.35.174 # IP of www.kuro5hin.org Rusty # Redirect all hostless requests to www VHost Rusty VirtualHost 216.181.35.174 Rusty ServerName kuro5hin.org Rusty Redirect permanent / http://www.kuro5hin.org/ Rusty /VirtualHost Rusty # Proper URI for www.kuro5hin.org Rusty VirtualHost 216.181.35.174 Rusty ServerName www.kuro5hin.org Rusty ...etc... Rusty /VirtualHost Rusty This way, people who come in to http://kuro5hin.org/ get redirected Rusty right off the bat, and so far this seems to have solved the problem. Except that this requires HTTP/1.1. Anyone that doesn't send the "host:" header goes into a permanent redirect loop. [...] Not if you do it right[tm] and have the "real" host be the default. - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 70M impressions per day, http://valueclick.com
Re: [slightly OT] Problem with cookies
"Kee" == Kee Hinckley [EMAIL PROTECTED] writes: Kee Well, the good news is that if they don't support Host:, they Kee certainly aren't going to support cookies! Why? Those are orthogonal features. HTTP/1.0 did not require "host:". And certainly, browsers that handled HTTP/1.0 had cookies. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: [slightly OT] Problem with cookies
Cliff, I thought about that, but according to the CGI.pm docs (and the netscape cookie specs too), you have to have at least two(2) dots so that you can't match things like .edu or .com. The .domain.com is supposed to match all hosts containing domain.com. Argh! Thanks for the thought, I'll look into it further. ___cliff rayman___ wrote: The domain in the Set-Cookie header is '.cloudstock.com'. According to every spec I've read, this should work properly. I telnetted to just a guess here but, 'cloudstock.com' does not match '.cloudstock.com' when you set the domain as '.cloudstock.com' you are saying that the domain should end in those characters. since cloudstock.com does not have a leading period, it will not match. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704.370.0550 http://www.vialogix.com
Re: [slightly OT] Problem with cookies
On Thu, 6 Apr 2000, Drew Taylor wrote:
I have a site which uses cookies for user tracking. If you go to
http://cloudstock.com/, the server is sending the cookie but the browser
is not accepting it ("warn before accepting cookie" is on). If I go to
http://www.cloudstock.com/ the cookie is sent accepted.
Does your Set-Cookie header include a path setting? Some browsers require
that.
- Perrin
Re: [slightly OT] Problem with cookies
Perrin Harkins wrote: Does your Set-Cookie header include a path setting? Some browsers require that. Yes, it sets the path to '/'. I'm sitting here scratching my head. I'm doing everything I know to do and it's not working... :-( Here's the relevant code: ($domain is 'cloudstock') my $cookie = $CGI-cookie( -name = 'cookieName', -value = $cookievalue, -path = '/', -domain = ".$domain.com", -expires = $expires); -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704.370.0550 http://www.vialogix.com
Re: [slightly OT] Problem with cookies
Drew Taylor wrote: Perrin Harkins wrote: Does your Set-Cookie header include a path setting? Some browsers require that. Yes, it sets the path to '/'. I'm sitting here scratching my head. I'm doing everything I know to do and it's not working... :-( Here's the relevant code: ($domain is 'cloudstock') my $cookie = $CGI-cookie( -name = 'cookieName', -value = $cookievalue, -path = '/', -domain = ".$domain.com", -expires = $expires); Here is the result of a telnet to port 80 [drew@yoda drew]$ telnet cloudstock.com 80 Trying 216.48.12.177... Connected to cloudstock.com. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.1 200 OK Date: Thu, 06 Apr 2000 21:42:15 GMT Server: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix) mod_perl/1.21 Set-Cookie: customerID=hash02dc0fe4f99825ccb7dd5ef643196a93ID177reg0time955057336; domain=.cloudstock.com; path=/; expires=Fri, 06-Apr-2001 21:42:16 GMT Set-Cookie: lightboxID=hashb59e1bdb2340596c0ba0d7fe8d3d79f6ID184reg0time955057336; domain=.cloudstock.com; path=/; expires=Fri, 06-Apr-2001 21:42:16 GMT Connection: close Content-Type: text/html -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704.370.0550 http://www.vialogix.com
Re: [slightly OT] Problem with cookies
I tested this from my end also. I see the cookies being properly set when I do: lwp-request -e 'http://cloudstock.com' I get a cookie warning from Netscape when i get them via 'http://www.cloudstock.com'. no cookie warning from netscape and no cookies in cookie.txt when i access via 'http://cloudstock.com'. I did not read the RFC so I cannot comment on it, but I bet the guys at Netscape have not read that RFC either. I think Netscape is not accepting the cookie because of the beginning period in .cloudstock.com. This is either purposeful or accidental. Perhaps you can redirect to www.cloudstock.com in order to make sure the cookie is properly set. ___cliff rayman___ genwax.com Drew Taylor wrote: Drew Taylor wrote: Perrin Harkins wrote: Does your Set-Cookie header include a path setting? Some browsers require that. Yes, it sets the path to '/'. I'm sitting here scratching my head. I'm doing everything I know to do and it's not working... :-( Here's the relevant code: ($domain is 'cloudstock') my $cookie = $CGI-cookie( -name = 'cookieName', -value = $cookievalue, -path = '/', -domain = ".$domain.com", -expires = $expires); Here is the result of a telnet to port 80 [drew@yoda drew]$ telnet cloudstock.com 80 Trying 216.48.12.177... Connected to cloudstock.com. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.1 200 OK Date: Thu, 06 Apr 2000 21:42:15 GMT Server: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix) mod_perl/1.21 Set-Cookie: customerID=hash02dc0fe4f99825ccb7dd5ef643196a93ID177reg0time955057336; domain=.cloudstock.com; path=/; expires=Fri, 06-Apr-2001 21:42:16 GMT Set-Cookie: lightboxID=hashb59e1bdb2340596c0ba0d7fe8d3d79f6ID184reg0time955057336; domain=.cloudstock.com; path=/; expires=Fri, 06-Apr-2001 21:42:16 GMT Connection: close Content-Type: text/html -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704.370.0550 http://www.vialogix.com
Re: [slightly OT] Problem with cookies
On Thu, 6 Apr 2000, Perrin Harkins wrote:
On Thu, 6 Apr 2000, Drew Taylor wrote:
I have a site which uses cookies for user tracking. If you go to
http://cloudstock.com/, the server is sending the cookie but the browser
is not accepting it ("warn before accepting cookie" is on). If I go to
http://www.cloudstock.com/ the cookie is sent accepted.
Does your Set-Cookie header include a path setting? Some browsers require
that.
If you don't have the 'path' set it may be defaulting to the directory of
you request. So either way(blank or /some/dir) you could have problems
if you're not setting path=/.
-Ian
Re: [slightly OT] Problem with cookies
Hi Drew,
My site has several domains that lead into it and I had the same problem
with cookies that I fixed this way.
Here's how I ended up doing the redirections using mod_rewrite and a perl
script (which needed to be portable in my case). This could have probably
been done simpler and more effectively but I needed to guarantee that all
FORM variables were passed along seemlessly to the target domain and have
the script run correctly.
CAVEATS: The script treats a FORM variables in a hash fashion so it doesnt
deal with multi-selects
In httpd virtual host section:
RewriteEngine on
RewriteCond %{SCRIPT_FILENAME} (.+)
RewriteRule ^/cgi-bin/(.+)
http://www.condoms.net/cgi-bin/nph-redirect.cgi?URI=%1 [P,QSA]
RewriteRule ^/(.*) http://www.condoms.net/$1 [R]
The script nph-redirect.cgi:
#!/usr/bin/perl
use strict;
use CGI;
my $cgi = CGI-new;
my %form;
my $query_string;
# get a list of all of the form and query string fieldnames
my @form = $cgi-param();
my @url_params = $cgi-url_param();
# add all of the form variables to form
map { $form{$_} = $cgi-param($_); }
@form;
# add all of the query string vars to form
map { $form{$_} =
$cgi-url_param($_); } @form;
# get domain and uri
my $request_uri = $form{'URI'}|| '';
my $domain = $form{'DOMAIN'} ||
"http://www.condoms.net/";
# create the query string
foreach (keys %form) {
next if (uc($_) eq 'SUBMIT' || uc($_) eq
'URI' || uc($_) eq 'DOMAIN');
$query_string.= "$_=$form{$_}";
}
# remove the leading because of above loop (could do with counter above
but this is easier :)
$query_string=~ s/^//;
# add the ? if the query string actually has something
$query_string= "?$query_string" if ($query_string
!~ /^\s*$/);
my $url = "$domain$request_uri$query_string";
$url =~ s#/+#/#g;
$url =~ s#(https?:)/#$1//#;
print $cgi-redirect(-location = $url,
-nph = 1);
At 05:29 PM 04/06/00 -0400, you wrote:
Kee,
I'm about to that point. What is the easiest way to do this? I have one
IP for the domain. Should I have my scripts check SERVER_NAME do a
redirect? BTW, I have complete control over the box so I can do what I
want. :-)
Kee Hinckley wrote:
As a complete aside to your aside, I recommend against having two
domains point to the same site. Make the non-www one redirect to the
correct one. Otherwise you are going to get indexed twice by the
search engines (and twice as often) which makes the search results
look messy, and have less options to change what domain does what in
the future.
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704.370.0550
http://www.vialogix.com
Re: [slightly OT] Problem with cookies
At 05:29 PM 04/06/00 -0400, you wrote: Kee, I'm about to that point. What is the easiest way to do this? I have one IP for the domain. Should I have my scripts check SERVER_NAME do a redirect? BTW, I have complete control over the box so I can do what I want. :-) I think whoever said that http://cloudstock.com/ doesn't match .cloudstock.com might be right. I had a similar problem with cookies on kuro5hin.org. I needed to set a session=blah cookie for www.kuro5hin.org, and a *different* session cookie for scoop.kuro5hin.org. So I couldn't use .kuro5hin.org as the domain. But I wanted people who came to http://kuro5hin.org/ to go to www.kuro5hin.org by default. What I ended up doing was targeting cookies at a host (i.e. domain=www.kuro5hin.org), and setting up VirtualHost sections as follows: NameVirtualHost 216.181.35.174 # IP of www.kuro5hin.org # Redirect all hostless requests to www VHost VirtualHost 216.181.35.174 ServerName kuro5hin.org Redirect permanent / http://www.kuro5hin.org/ /VirtualHost # Proper URI for www.kuro5hin.org VirtualHost 216.181.35.174 ServerName www.kuro5hin.org ...etc... /VirtualHost This way, people who come in to http://kuro5hin.org/ get redirected right off the bat, and so far this seems to have solved the problem. --R PS- General comment: Cookies are a neat idea, but good lord are they ever a PITA to implement. :-/ -- === | Rusty Foster | "You can never entirely stop being what | | [EMAIL PROTECTED]| you once were. That's why it's important | |[EMAIL PROTECTED] | to be the right person today, and not put | | http://www.kuro5hin.org | it off till tomorrow."-Larry Wall | ===
Re: [slightly OT] Problem with cookies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 4:09 PM -0700 4/6/00, Christopher Taranto wrote: Hi Drew, My site has several domains that lead into it and I had the same problem with cookies that I fixed this way. Here's how I ended up doing the redirections using mod_rewrite and a perl script (which needed to be portable in my case). This could have probably been done simpler and more effectively but I needed to guarantee that all FORM variables were passed along seemlessly to the target domain and have the script run correctly. Why would you have form variables on the first time they hit the site? (And they'd have to be POST variables for it to matter, right?) But in any case. The easiest solution is probably to create a virtual domain in the config file and then specify a rule that redirects all URL's for that domain. Actually, now that I say this, I just realized that, having just moved my sites back to an Apache server, I'd forgotten to do it myself. So you get here an example that I have tested for all of about 2 minutes. So put this in the .conf file for Apache. # # The actual name of the host managing the sites # NameVirtualHost sam.somewhere.com # # Our catchall host. While this will catch somewhere.com specifically, it will also # catch any other host names that happen to point at the same IP address but that # you didn't specifically set a virtual host for. E.g. just an IP address, or mail.somewhere.com if that's the # same machine # VirtualHost sam.somewhere.com ServerName somewhere.com Redirect / http://www.somewhere.com/ /VirtualHost # Now we do the legitimate domains VirtualHost sam.somewhere.com ServerName www.somewhere.com ServerAlias www.stage.somewhere.com - -- Kee Hinckley - Somewhere Consulting Group - Cyberspace Architects(rm) I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.2 for non-commercial use http://www.pgp.com iQA/AwUBOO0fvSZsPfdw+r2CEQKrGwCfVMUCVW3+TfsH5RWXli6GKHS0rE8Anivt guYVKzV+OCCfXh1DVPxAB8VC =HkrY -END PGP SIGNATURE-
Re: [slightly OT] Problem with cookies
Rusty and Kee, The dual VirtualHost configuration is exactly the solution I will take! It will also apply it to the main domain as well - thinkstock.com, .org, and .net. That will solve my problem, as well as any future ones, and I can just be done with this stupid cookie problem! You just made my night better (and my morning too)! Yes, cookies are neat (and I thought it was better than session tracking via URL), but you are right when you say they are a pain!! Thanks a million! At 05:29 PM 04/06/00 -0400, you wrote: I had a similar problem with cookies on kuro5hin.org. I needed to set a session=blah cookie for www.kuro5hin.org, and a *different* session cookie for scoop.kuro5hin.org. So I couldn't use .kuro5hin.org as the domain. But I wanted people who came to http://kuro5hin.org/ to go to www.kuro5hin.org by default. What I ended up doing was targeting cookies at a host (i.e. domain=www.kuro5hin.org), and setting up VirtualHost sections as follows: NameVirtualHost 216.181.35.174 # IP of www.kuro5hin.org # Redirect all hostless requests to www VHost VirtualHost 216.181.35.174 ServerName kuro5hin.org Redirect permanent / http://www.kuro5hin.org/ /VirtualHost # Proper URI for www.kuro5hin.org VirtualHost 216.181.35.174 . ServerName www.kuro5hin.org ...etc... /VirtualHost Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704.370.0550 http://www.vialogix.com
