184494 - statelinetack.com - Shopping basket forgotten when going to from http to https

Status: RESOLVED INCOMPLETE

(Tech Evangelism Graveyard :: English US, defect)

Description

[Heikki Toivonen (remove -bugzilla when emailing directly)]

When you are trying to checkout with your purchases from this site, it always
thinks your shopping cart is empty. I suspect this is because Mozilla does not
send the cookies in this situation: selecting products is done in unsecure mode,
and checkout takes you to an SSL URL.

I am not sure if this is our bug or an evangelism issue or what, but this seems
to happen with latest trunk builds as well as with NS 7.0. I seem to remember
there was some talk about this issue recently, but I can't seem to find it.
Works fine with latest IE. The funny thing is that the site otherwise seems to
work better with Mozilla (some images won't display with IE).

To reproduce:

1. Go to URL (http://statelinetack.com)
2. Select some product (for example, follow these links: STABLE -> Turnouts &
Hoods -> WeatherBeeta TAKA 1600TS Regular Neck Sheet) and hit "Add to cart" button.
3. From resulting shopping basket summary page hit "Secure Checkout" button.
NOTE: Up till now you have been on unsecure pages, and this button should take
you to an SSL URL.

Expected results: a page where you fill in credit card info etc.

Actual results: a page that says your cart is empty.

Comment 1

[Jo Hermans]

Reporter, have you selected 'enable cookies for the originating sitre only' ?

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

My settings make it use the medium P3P settings which should not reject any
cookies. I just tested with "enable all cookies" and I still see this bug.

Comment 3

[Stephen P. Morse]

Here's some info.  Not the full answer yet, but I'm still investigating.

This fails with N4 as well.  Problem appears to be that Heikki started by going
to http://statelinetack.com (with non www) and the cookies are then set as host
cookies for statelinetack.com.  Then when you go to check out, the site sends
you to https://www.statelinetack.com.  So the host cookies that were set for the
statelinetack.com host do not get sent to this secure host.

In N4, if I start by going to http://www.statelinetack.com, everything works
fine.  So at first I thought that I had found the cause of the problem, and it
was one of evangelism (there's a similar problem if you start at google.com
instead of www.google.com).  But apparently that's not the whole problem
because, upon investigating further, I observed the following:

- If I start from http://www.statelinetack.com in mozilla, the problem still occurs.

- If I start from http://statelinetack.com, there is no problem.

So I'm still investigating.

Comment 4

[Stephen P. Morse]

Correction: I was wrong above when I said that there is still a problem when
starting from http://www.statelinetack.com in mozilla.  After I fixed a bug in
my local tree (bug was not checked in), this worked fine in mozilla.  So the
problem is indeed a site problem and not a browser one.  The site should take
you to https://statelinetack.com if you started from http://statelinetack.com,
and then the cookies from the non-secure server will correctly be sent to the
secure one.

The only thing that I still can't explain is why this works on IE.  Still
investigating.

Comment 5

[Stephen P. Morse]

OK, I understand the problem.  Microsoft is playing fast and loose with the
definition of domain matching.  That is, if a cookie is set for host B, they are
sending those cookies to host A.B.  This is in violation of the cookie spec
RFC-2109.

To demonstrate this, go to http://netscape.com, and set a cookie by using a
javascript URL.  You do that by typing the following into the URL bar

   javascript:document.cookie="mycookie=abc";

Then go to http://home.netscape.com and read the cookies using a javascript URL:

   javascript:alert(document.cookie);

Note that mycookie will be readable at this time.  (If you set a cookie when at
home.netscape.com, you will not be able to read it when at netscape.com.)

It's because of this violation of the cookie spec that the shopping cart works
with IE if you start from http://statelinetack.com.

So what do we do about this?  I'd really love to see this fixed by evangelism. 
Someone needs to inform statelinetack.com that they have the wrong expectations
of seeing the cookies on their secure severe with the www if those cookies were
initially set on their unsecure sever without the www.

The other alternative is for us to change our cookie code and violate the cookie
spec in the same manner that Microsoft is doing.  I'm against doing that.  We
are supposed to be generating a better browser because ours is
standards-compliant whereas the microsoft browser it not.

Incidentally, regarding the google.com problem that I mentioned above, I see
that google has become aware of the problem and has solved it.  Now when you go
to http://google.com, you automatically get redirected to http://www.google.com.

Reassigning to evangelism to see if we can get statelinetack to see the error of
their ways.

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Thanks for the quick diagnosis, Steve! I agree I'd rather see this fixed on the
site.

I think State Line Tack is an American company, though, so changing components.

Comment 7

[Yves Lambert]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b; MultiZilla v1.1.33 (b))
Gecko/20030111
wfm as far as i erased all cookies before proceeding. if not the cart is empty too.
--> general cookie problem?
reporter: what version are you using?

Comment 8

[Yves Lambert]

BTW the test Stephen proposes fails. the alert box is empty for me.
please check depandancies (Evangelism.Ecommerce and browser.cookies)
bug 170396 and other microsoft cookies issues

Comment 9

[Bob Clary [:bc] (inactive)]

tech evang june 2003 reorg

Comment 10

[Chris Lawson (gone)]

INCOMPLETE due to lack of activity since the end of 2009.

If someone is willing to investigate the issues raised in this bug to determine whether they still exist, *and* work with the site in question to fix any existing issues, please feel free to re-open and assign to yourself.

Sorry for the bugspam; filter on "NO MORE PRE-2010 TE BUGS" to remove.