Cookie Problem on Safari


#1

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


#2

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


#3

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.


#4

Rob B. 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 B. http://agileconsultingllc.com
removed_email_address@domain.invalid

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


#5

Could you let me know the bug # so I can follow up on it?

(I’m a Safari QA engineer, and every once in a while I mine this list
to see if all bugs are being tended to.)

On Thu, May 8, 2008 at 9:20 AM, Phillip K.


#6

Deirdre Saoirse M. wrote:

Could you let me know the bug # so I can follow up on it?

(I’m a Safari QA engineer, and every once in a while I mine this list
to see if all bugs are being tended to.)

On Thu, May 8, 2008 at 9:20 AM, Phillip K.

It doesn’t appear to be a bug after all. A couple of the more
knowledgeable readers of this list pointed out that the underscore is
not part of the standard, and therefore Safari is just being compliant.
It was my mistake, not Safari’s.

Peace,
Phillip


#7

Phillip K. wrote:

Deirdre Saoirse M. wrote:

Could you let me know the bug # so I can follow up on it?

(I’m a Safari QA engineer, and every once in a while I mine this list
to see if all bugs are being tended to.)

On Thu, May 8, 2008 at 9:20 AM, Phillip K.

It doesn’t appear to be a bug after all. A couple of the more
knowledgeable readers of this list pointed out that the underscore is
not part of the standard, and therefore Safari is just being compliant.
It was my mistake, not Safari’s.

Peace,
Phillip

Seems like a bug to me. The standard says that underscores are not
valid in hostnames. By that logic your site would not work, or not be
accessible if it was using an underscore.

The fact that your site worked fine, but the browser would not accept
cookies for the domain is a bug for sure. It resulted in you having to
pull out a packet sniffer in order to figure it out. Anything that
causes that much frustration for developers is probably something the
Safari team wants to get ironed out.

The expected to behavior would be that that would either work 100%, or
it would not work at all. Not some confusing mix in the middle of
partially working functionality.


#8

Alex W. wrote:

Seems like a bug to me. The standard says that underscores are not
valid in hostnames. By that logic your site would not work, or not be
accessible if it was using an underscore.

The fact that your site worked fine, but the browser would not accept
cookies for the domain is a bug for sure. It resulted in you having to
pull out a packet sniffer in order to figure it out. Anything that
causes that much frustration for developers is probably something the
Safari team wants to get ironed out.

The expected to behavior would be that that would either work 100%, or
it would not work at all. Not some confusing mix in the middle of
partially working functionality.

Ah, well, good points. In either case, I don’t have a bug number. I used
the Report Bugs to Apple… option under the Safari menu.

Peace,
Phillip


#9

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

::= | " "

::= | “.”

::= [ [ ] ]

::= |

::= | “-”

::= |

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

::= 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 B. http://agileconsultingllc.com
removed_email_address@domain.invalid