Ruby Forum Ruby on Rails > Cookie Problem on Safari

I have a 2.0.2 app that I'm developing locally using Mongrel.  I'm using
active_record_store for sessions and have uncommented the secret in the
protect_from_forgery call.  Everything works fine locally.

I uploaded the app to my server yesterday so I could show some progress
to a client.  The server is running LiteSpeed Standard 3.3.11.  The app
works correctly in Firefox, but not in Safari (3.1.1 Mac). I tracked the
problem down to the session_id cookie not being created in Safari, so a
new session is created on every server hit and I get blasted with
InvalidAuthenticityToken errors.

Since I have cookies enabled in Safari (it's my primary browser), my
first thought was LiteSpeed is not writing cookies to Safari correctly,
if that's even reasonable. To test that theory, I launched another
application that I have had on that server for many months and has been
working fine.  But to be thorough, I made sure it wrote a cookie
correctly.  The odd thing is that it's a Rails 1.2.3 application, but is
using the cookie session store. Since cookies work correctly in the
1.2.3 app but not in the 2.0.2 app, I'm inclined to think this is a
Rails problem and not a LiteSpeed one.

Has anyone else experienced this? I have not yet been able to find any
related posts via this forum or Google, but I might not have hit on the
right search term combination yet.

Any help or direction will be very much appreciated.

Peace,
Phillip

After analyzing packets with tcpdump and comparing Firefox and Safari 
hitting LiteSpeed, Mongrel, and Apache, I discovered the problem on a 
whim.

Underscores in the hostname.

Yes, you read that correctly.  Apparently Safari 3.1.1 will not write a 
session cookie if there are underscores in the hostname.  My original 
dilemma was with the URL

sports_dev.livingdoor.net

and the working site on the same server was

vsiep.livingdoor.net

I set up a more controlled test with new applications (in both Rails 
1.2.6 and 2.0.2) and the urls were

cookie_test_126.livingdoor.net
cookie_test_202.livingdoor.net

The cookie did not get created in Safari for either one.  But when I 
changed one of them to

cookietest202.livingdoor.net

the cookie was successfully created.

I have submitted a bug report to Apple.

Peace,
Phillip

This is from the Uniform Resource Identifier (URI): Generic Syntax

2.3. Unreserved Characters


   Characters that are allowed in a URI but do not have a reserved
   purpose are called unreserved.  These include uppercase and
lowercase
   letters, decimal digits, hyphen, period, underscore, and tilde.

      unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"

http://tools.ietf.org/html/rfc3986

Through the years I have had numerous of issues using with clients
using underscore in their domain name. It's my recommendation to not
use underscore in your url.

On May 8, 2008, at 2:06 PM, heimdull wrote:
>
> http://tools.ietf.org/html/rfc3986
>
> Through the years I have had numerous of issues using with clients
> using underscore in their domain name. It's my recommendation to not
> use underscore in your url.


More specifically, the host name is constrained to have only letters,
digits, and hypens per http://tools.ietf.org/html/rfc1035  (section
2.3.1 reproduced here):

==================================================
2.3.1. Preferred name syntax

The DNS specifications attempt to be as general as possible in the rules
for constructing domain names.  The idea is that the name of any
existing object can be expressed as a domain name with minimal changes.



Mockapetris                                                     [Page 7]
RFC 1035        Domain Implementation and Specification    November 1987


However, when assigning a domain name for an object, the prudent user
will select a name which satisfies both the rules of the domain system
and any existing rules for the object, whether these rules are published
or implied by existing programs.

For example, when naming a mail domain, the user should satisfy both the
rules of this memo and those in RFC-822.  When creating a new host name,
the old rules for HOSTS.TXT should be followed.  This avoids problems
when old software is converted to use domain names.

The following syntax will result in fewer problems with many

applications that use domain names (e.g., mail, TELNET).

<domain> ::= <subdomain> | " "

<subdomain> ::= <label> | <subdomain> "." <label>

<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig-hyp> ::= <let-dig> | "-"

<let-dig> ::= <letter> | <digit>

<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case

<digit> ::= any one of the ten digits 0 through 9

Note that while upper and lower case letters are allowed in domain
names, no significance is attached to the case.  That is, two names with
the same spelling but different case are to be treated as if identical.

The labels must follow the rules for ARPANET host names.  They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen.  There are also some
restrictions on the length.  Labels must be 63 characters or less.

For example, the following strings identify hosts in the Internet:

A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
==================================================

So it is more likely correct behavior from Safari in its refusal to
store a cookie with an underscore-containing host name.

-Rob

Rob Biedenharn    http://agileconsultingllc.com
Rob@AgileConsultingLLC.com

Rob Biedenharn wrote:
> 
> So it is more likely correct behavior from Safari in its refusal to
> store a cookie with an underscore-containing host name.
> 
> -Rob
> 
> Rob Biedenharn    http://agileconsultingllc.com
> Rob@AgileConsultingLLC.com

Thanks to both of you for clarifying that.  It's frustrating that 
Firefox makes an allowance for the underscore.  In my naivete, I assumed 
that it was a bug in Safari and not a departure from the standards in 
Firefox.

Peace,
Phillip