|
Re: Warn people who have perlmonks in a URL?
by jonadab (Parson) on Nov 09, 2003 at 01:11 UTC
|
If www.perlmonks.org and perlmonks.org cannot share the
same cookie, even though one is a CNAME for the other
and they are in the same domain, this strikes me as
either a browser bug or possibly a design flaw in the
cookie specification. Many systems have multiple
machine names and yet should be considered the same
system. I would understand if they were in different
domains (e.g., www.foo.org and cgi.bar.org), but such
is not the case.
However, doesn't Apache have a feature that will fix
this, by rewriting the URI to have a certain machine
name? (I'm thinking something about canonical names,
but my memory is a little hazy on the details.) Or
am I confused about that?
As far as the .com and .net domains... I'd be
interested in hearing the reasoning behind why
those TLDs don't just do a refresh/redirect
to the .org domain. I can sort-of understand
the reasoning behind registering perlmonks.com,
because of people who get all their ideas about
the internet from television (do such people read
sites like perlmonks, though?), but I have difficulty
believing *anyone* would think perlmonks would belong
in the .net TLD, and it seems to me that even given
that you want people who type in those domains to
get to the right place, a refresh would accomplish
that, and still land everyone's URIs in the same TLD,
which would have more benefits than just making
absolute links work better. What am I missing?
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
| [reply]
[d/l] |
|
|
this strikes me as either a browser bug or possibly a design flaw in the cookie specification.
It's neither. If anything, it's a bug in the way perlmonks is implemented. Apparently, the cookie sent is dependent on the server requested. It might be better to always send a cookie for the domain instead.
Note that if you are logged into perlmonks.org and a link takes you to www.perlmonks.org it will work just fine. It's only the other direction that breaks.
As far as the .com and .net domains... I'd be interested in hearing the reasoning behind why those TLDs don't just do a refresh/redirect to the .org domain.
That's a good question. I'll be interested in hearing the answer to that as well. I suspect it is an attempt to be friendly to clients that don't handle redirects transparently (or at all.) But, I think redirecting the other domains makes sense.
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
|
|
If anything, it's a bug in the way perlmonks is implemented. Apparently, the cookie sent is dependent on the server requested. It might be better to always send a cookie for the domain instead.
In other words, you're saying that they *can* share the
cookie. If that is the case, I think it would be better
to have them do so, than to try to train users to deal
with the fact that they don't. (Yeah, I know, I'm not
the poor admin who has to implement all these crazy
demands the users have...)
I suspect it is an attempt to be friendly to clients that don't handle redirects transparently (or at all.)
The standard way to deal with that is to send, along
with the refresh/redirect, a small page containing
a link. But I suspect very few users would ever see
the link, because all the major graphical browsers
can handle refresh since about 1995, and people who
use Lynx generally have been around on the net for a
little while and probably aren't going to be trying
to use a .com TLD to access a site like perlmonks,
unless they're either fooling around or testing the
site. (I'm assuming here that in addition to an HTTP
refresh header you also include an http-equiv refresh
in the <head> section of the document.
With doing both those things, browser support is
near universal.) I'm trying to imagine a Lynx user
who would think of perlmonks and immediately guess,
"It's probably a commerce site." A surreal notion.
But if you include the link in the response along
with the refresh, you cover even this edge case.
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
|
|
|
|
Note that if you are logged into perlmonks.org and a link takes you to www.perlmonks.org it will work just fine. It's only the other direction that breaks
What you're seeing is the domain value of the cookie (see CGI::Cookie). By default, the domain is the machine you're on. You can explicitly set if anywhere up your food chain. So, as an example - www.perlmonks.org can set it's domain value to perlmonks.org but perlmonks.org cannot set it's domain value to www.perlmonks.org. If you log into perlmonks.org, www.perlmonks.org can see the cookie.
Oren
| [reply] |
|
|
|
|
Note that if you are logged into perlmonks.org and a link takes you to www.perlmonks.org it will work just fine.
No it doesn't. Not on Firebird ("Mozilla Lite") on Win32. I just tested it. While I'm at it: it doesn't work on the normal Mozilla, Netscape 7, Netscape 4.79.
However, it does seem to work on MSIE5.5. Uncle Bill seems to have done it his own way, once again.
BTW I think that it's possible to specify cookies that do work for both domains. But you have to specify it in a specific way... something to do with a leading dot. For details, see the cookies RFC
| [reply] |
|
|
|
|
However, doesn't Apache have a feature that will fix this, by rewriting the URI to have a certain machine name?
That won't help if you don't do tell the client to go to a different URL - it's the user agent which decides which cookies to send along with a request to what host.
Makeshifts last the longest.
| [reply] |