Re: [slightly OT] Problem with cookies

[Randal L. Schwartz]

> "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]> 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 L. Schwartz]

> "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]> 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 Hinckley]

-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 

iQA/AwUBOO+ZuiZsPfdw+r2CEQK1UwCdG8FM7uRy8NgSEB4stnTHeegI13oAoKIh
Ft3/euj1jPY71I7laJaBU/6x
=Ue8l
-END PGP SIGNATURE-

RE: [slightly OT] Problem with cookies

[Jeff Stuart]

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

[Kee Hinckley]

-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 

iQA/AwUBOO9ihSZsPfdw+r2CEQJR6ACgkeu3CQy39slkB7+Pg6rgcBg7M8AAn0Iv
TLOuIwPOrzqyDAErK0N16ye0
=plvO
-END PGP SIGNATURE-

Re: [slightly OT] Problem with cookies

[Randal L. Schwartz]

> "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]> 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

[Ask Bjoern Hansen]

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> 
> Rusty> ServerName kuro5hin.org
> Rusty> Redirect permanent / http://www.kuro5hin.org/
> Rusty> 
> 
> Rusty> # Proper URI for www.kuro5hin.org
> Rusty> 
> Rusty>   ServerName www.kuro5hin.org
> Rusty>   ...etc...
> Rusty> 
> 
> 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 - 
more than 70M impressions per day, 

Re: [slightly OT] Problem with cookies

[Kee Hinckley]

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

[Drew Taylor]

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

[Rusty Foster]

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
> >
> >ServerName kuro5hin.org
> >Redirect permanent / http://www.kuro5hin.org/
> >
> >
> ># Proper URI for www.kuro5hin.org
> >
> >  ServerName www.kuro5hin.org
> >  ...etc...
> >
> 
> 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

[Bill Moseley]

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
>
>ServerName kuro5hin.org
>Redirect permanent / http://www.kuro5hin.org/
>
>
># Proper URI for www.kuro5hin.org
>
>  ServerName www.kuro5hin.org
>  ...etc...
>

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.

Bill Moseley
mailto:[EMAIL PROTECTED]

Re: [slightly OT] Problem with cookies

[Perrin Harkins]

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

[Jim Winstead]

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

[Randal L. Schwartz]

> "Ken" == Ken Y Clark <[EMAIL PROTECTED]> writes:

Ken> i'm just learning about the beautiful magic of the RewriteEngine.  could
Ken> this be a good solution for you?  in order to make sure cookies always
Ken> work properly on http://mp3.boston.com which is aliased as
Ken> http://music.boston.com, we use the following RewriteRule:

Ken> RewriteEngine on
Ken> RewriteCond %{HTTP_HOST}   !^mp3\.boston\.com   [NC]
Ken> RewriteRule ^/(.*) http://mp3.boston.com/$1 [L,R]

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.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> 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 Taylor]

Ken,

I've just checked & mod_rewrite is installed on the server in question.
I think this is the most elegant, as well as fool-proof solution. I
don't know much about mod_rewrite (yet!), but I'm guessing the
RewriteCond checks to make sure the host is whatever.domain.com. The
RewriteRule transfers the remainder of the path to the new host. Is this
right?

I managed to find Ralf's tutorial on mod_rewrite on his website (Cool
design BTW Ralf!). The URL is:
http://www.engelschall.com/pw/apache/rewriteguide/


"Ken Y. Clark" wrote:

> 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]


-- 
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

[Ken Y. Clark]

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

[Drew Taylor]

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> 
> Rusty> ServerName kuro5hin.org
> Rusty> Redirect permanent / http://www.kuro5hin.org/
> Rusty> 
> 
> Rusty> # Proper URI for www.kuro5hin.org
> Rusty> 
> Rusty>   ServerName www.kuro5hin.org
> Rusty>   ...etc...
> Rusty> 
> 
> 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

[Randal L. Schwartz]

> "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]> 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 L. Schwartz]

> "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> 
Rusty> ServerName kuro5hin.org
Rusty> Redirect permanent / http://www.kuro5hin.org/
Rusty> 

Rusty> # Proper URI for www.kuro5hin.org
Rusty> 
Rusty>   ServerName www.kuro5hin.org
Rusty>   ...etc...
Rusty> 

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]> 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 Taylor]

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
>
>ServerName kuro5hin.org
>Redirect permanent / http://www.kuro5hin.org/
>
>
># Proper URI for www.kuro5hin.org
>
>.  ServerName www.kuro5hin.org
>  ...etc...
>


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

[Christopher Taranto]

>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?)

Because not all people come in the front door - such as banner ads that
implement a search, etc...

Not only that, but you would want to identify where they came in from.  We
use a GC code (standing for geography code) that allows us to tag a unique
identifier from different banners so we can get test our effectiveness of
our ads and end up with a conversion rate.


At 07:36 PM 04/06/00 -0400, you wrote:
>-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
>#
>
> ServerName somewhere.com
> Redirect / http://www.somewhere.com/
>
>
># Now we do the legitimate domains
>
>
> 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 
>
>iQA/AwUBOO0fvSZsPfdw+r2CEQKrGwCfVMUCVW3+TfsH5RWXli6GKHS0rE8Anivt
>guYVKzV+OCCfXh1DVPxAB8VC
>=HkrY
>-END PGP SIGNATURE-
>
>

Re: [slightly OT] Problem with cookies

[Kee Hinckley]

-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
#

 ServerName somewhere.com
 Redirect / http://www.somewhere.com/


# Now we do the legitimate domains


 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 

iQA/AwUBOO0fvSZsPfdw+r2CEQKrGwCfVMUCVW3+TfsH5RWXli6GKHS0rE8Anivt
guYVKzV+OCCfXh1DVPxAB8VC
=HkrY
-END PGP SIGNATURE-

Re: [slightly OT] Problem with cookies

[Rusty Foster]

> 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

ServerName kuro5hin.org
Redirect permanent / http://www.kuro5hin.org/


# Proper URI for www.kuro5hin.org

  ServerName www.kuro5hin.org
  ...etc...


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

[Christopher Taranto]

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

[Ian Struble]

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

[Drew Taylor]

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

[Kee Hinckley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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.
- -- 

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 

iQA/AwUBOO0OTyZsPfdw+r2CEQL+/wCcDoeGWzP6xLIFZijkgs1FfAvECGAAoPN6
fUjKzz/QWFnYdWgsYP3ZTBqu
=T+Dh
-END PGP SIGNATURE-

Re: [slightly OT] Problem with cookies

[___cliff rayman___]

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=hash&02dc0fe4f99825ccb7dd5ef643196a93&ID&177®&0&time&955057336;
> domain=.cloudstock.com; path=/; expires=Fri, 06-Apr-2001 21:42:16 GMT
> Set-Cookie:
> lightboxID=hash&b59e1bdb2340596c0ba0d7fe8d3d79f6&ID&184®&0&time&955057336;
> 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

[Drew Taylor]

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=hash&02dc0fe4f99825ccb7dd5ef643196a93&ID&177®&0&time&955057336;
domain=.cloudstock.com; path=/; expires=Fri, 06-Apr-2001 21:42:16 GMT
Set-Cookie:
lightboxID=hash&b59e1bdb2340596c0ba0d7fe8d3d79f6&ID&184®&0&time&955057336;
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

[Drew Taylor]

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

[Perrin Harkins]

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

[Drew Taylor]

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

[___cliff rayman___]

 
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.
cliff rayman
genwax.com