1355729 - Quoted values in cookies do not work

Status: RESOLVED WORKSFORME

(Core :: Networking: Cookies, defect, P2)

Description

[jounijl]

User Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46
Build ID: 20170225110252

Steps to reproduce:

I was developing a www-service and tested different web browsers with my www-service set cookies. I had set the cookie as follows according to Page 9, RFC 6265 "4.1.1. Syntax":

Cookie not working in Seamonkey 2.46 and Chromium 54 (works in Opera 12.16):

Set-Cookie: TEST=12341234123412341234123412341234123412341234; Expires=Mon Apr 10 15:50:00 2017; Max-Age=14400 ; Path="/"; Domain="server.mydomain.com"; Secure; HttpOnly

Cookie working in Seamonkey, Chromium and Opera:

Set-Cookie: TEST=12341234123412341234123412341234123412341234; Expires=Mon Apr 10 15:50:00 2017; Max-Age=14400 ; Path=/; Domain=server.mydomain.com; Secure; HttpOnly

The syntax should be:

cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )




Actual results:

The Seamonkey 2.46 and Chromium 54 did not send the cookie to my www-service if I had used (standard?) quotes around the values. Cookies work only without quotes in Seamonkey 2.46.

The news group forum gave a hint this may be a bug in Gecko:
http://forums.mozillazine.org/viewtopic.php?f=5&t=3029206

More information and original post:
http://forums.mozillazine.org/viewtopic.php?f=40&t=3028777&p=14740013&hilit=broken+HTTPS+cookie#p14740013 


Expected results:


The web browser engine (Gecko?) should be able to use as well the double quotes around the cookie values.

Is there any reason the double quotes could not be used around the cookie values?

Comment 1

[Frank-Rainer Grahl (:frg)]

Cookie handling is in Gecko not SeaMonkey. Rerouting.

Comment 2

[jounijl]

An easy cgi script to reproduce the bug. Text can be changed:

#!/bin/sh
echo "Content-Type: text/plain"
echo "Set-Cookie: TEST=\"12341234...\"; Max-Age=14400 ; path=\"/\"; secure; httponly"
echo
pwd
env | sort

Comment 3

[Dragana Damjanovic [:dragana]]

Amy, can you take a look?

Comment 4

[Amy Chung [:Amy]]

Ok, I will take a look at this.

Comment 5

[Amy Chung [:Amy]]

Hi,
Would you offer me http log?
You could refer to https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging.
And please add cookie log when you set MOZ_LOG, you could set MOZ_LOG as below:
export MOZ_LOG=timestamp,rotate:200,nsHttp:5,nsSocketTransport:5,nsStreamPump:5,nsHostResolver:5,cookie:4

Thanks!

Comment 6

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 7

[jounijl]

Attachment: moz_about_networking.png

Comment 8

[jounijl]

Sorry for the delay. I'm running FreeBSD current at the moment and I'm not willing to update the browser version. I have to compile some packages from the sources if I update because of some issues with the libraries. This is a development version. I'm working with something else at the same time. Today I had time to test these instructions to log. The CGI environment needed to be reinstalled.

The log does not appear at this version (or build) of the Seamonkey software. I tried to start with:

$ env | grep MOZ
MOZ_LOG_FILE=/tmp/log.txt
MOZ_LOG=timestamp,rotate:200,nsHttp:5,nsSocketTransport:5,nsStreamPump:5,nsHostResolver:5,cookie:4

and the log did not appear there. The version is:

User agent: Mozilla/5.0 (X11; FreeBSD i386; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46
Build identifier: 20170622014734

The previous png-image is a screenshot of the user interface of "about:networking" as in the instructions. There is no "logging" section. At least not visible. Did I understood this correctly.?

I have already fixed this issue in my application server and older browsers work with it as well :) . This issue is similar to all of the users and not particularly with me. I hope I can still help.

Comment 9

[jounijl]

Sorry I made a mess here for you. The log finally appeared, sorry. It is attached. The last try is the "not working case":

Not working CGI script (cookie is not set in Seamonkey):

#!/bin/sh
echo "Content-Type: text/plain"
echo "Set-Cookie: TEST2=\"2224123412341234123412341234123412341234123412341234123412341234\"; Max-Age=14400 ; path=\"/\"; Domain=\"venue.7on.fi\"; secure; httponly"
echo
pwd
env | sort

Working CGI script (cookie is set in Seamonkey):

#!/bin/sh
echo "Content-Type: text/plain"
echo "Set-Cookie: TEST2=\"2224123412341234123412341234123412341234123412341234123412341234\"; Max-Age=14400 ; path=\"/\"; Domain=venue.7on.fi; secure; httponly"
echo
pwd
env | sort


The quotes around the domain make the cookie not usable. Even quotes around the value work. Quotes around the domain make the cookie to not to attach in Seamonkey.

Comment 10

[jounijl]

Attachment: moz_log.txt

The last request in the log is the failing request.

Comment 11

[Amy Chung [:Amy]]

Hi,
I found the reason of setting cookie fail from your log.
Because the host of cookie is "venue.7on.fi", when nsCookieSerivce checked the domain is current or not, we don't remove quoted values.
Base on above reason, the host name is "venue.7on.fi" and the url domain is venue.7on.fi, the checking function would verify theses hosts are different.
Also, Spec doesn't define we have to remove quoted values when checking domain.
In my view, I would choose WORKSFORME to close this bug.

If you have any other suggestions, please feel free to reopen this bug.
Thanks!

Comment 12

[jounijl]

The "spec" RFC 6265 allows a double quoted value. In all of the key-value -pairs, there is an option to add double quotes around the value of the key-value -pair. These are similar with every key-value pair. [
https://tools.ietf.org/html/rfc6265#section-4.1 ]

Is it possible to use double quotes in the domain name these days? At least the localizations are now possible, 
different encodings. If the quotes are not allowed, there is no reason to not to allow quoted values. Is there a bypass character to be used to add a quote in the value? There is not bypass specified in the "spec" 6265. Is this domainname in URL-encoding?
 
I have here tested only the domain name. The same result can be get with adding a directory or the path part in the
value. Of course, the first lines in the log were in error as you have mentioned, after the irrelevant domain name in 
the log, the results with the correct domain name is found with the local resolver found name as you have mentioned.

For me this is an error to be fixed either in the relevant spec (what that might be?) or the Gekko engine. For example 
the Opera browser works as RFC 6265 specifies. If 6265 is the correct one, this is a bug in Seamonkey (and the Gekko  
engine).

I'm not closing this as "works for me" because it is irrelevant considering the bug, ie. I have read the comments and the comments do not solve anything.

Comment 13

[Amy Chung [:Amy]]

Hi,
The RFC 6265 4.1 define the domain as below:
domain-value      = <subdomain>
                       ; defined in [RFC1034], Section 3.5, as
                       ; enhanced by [RFC1123], Section 2.1
And the domain define as below from RFC 1034 3.5(https://tools.ietf.org/html/rfc1034#section-3.5)
<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

Base on RFC 1034, it seems that the first letter of domain only can define 0-9 or A-Z and a-z.

In my view, the domain can't use quoted values.

Comment 14

[jounijl]

Currently I don't have time for this and the "reopen when needed" is a good choice for me as was suggested. I'm writing this to know that the next answer may take a long time. Maybe someone else could know an answer to this question. Isn't it Iana defining the domain name system and the RFC:s are not the ones to look at to find the right answers. Are these the correct specs and so on.

Comment 15

[jounijl]

Thanks.

Comment 16

[Daniel Stenberg [:bagder]]

The 'domain' parameter in cookies has never been used with quoted values so RFC6265 documented the state of the implementations and use of cookies at the time of writing. It was not quoted in cookies before that RFC was written either and it was not spelled out as allowed in the original netscape spec (stored here for anyone's pleasure https://curl.haxx.se/rfc/cookie_spec.html). Trying to use domain quoted now is begging for problems.