> "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 cam
> "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
-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
ead [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 th
-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 ce
> "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 c
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> # Pr
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. Th
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 sendi
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
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
>
>
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
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
> "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
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 transfer
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
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 wha
> "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
Dr
> "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> # Pro
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 m
>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
-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
> 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 thin
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 ef
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
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
-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 make
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://clo
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 c
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 $co
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 s
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
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 e
Hi all,
This post is a little off topic, but since I'm using mod_perl... here
goes. :-)
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
34 matches
Mail list logo
