Login | Register
My pages Projects Community openCollabNet

Discussions > dev > RE: FW: cookie handling by joist and noodle

Project highlights: Architectural Overview

Discussion topic

2020-04-07: This site is going to be decommissioned and shut down on 2020-07-01. Please copy and archive any data you wish to keep before that date.

Back to topic list

RE: FW: cookie handling by joist and noodle

Author Andy Cooke <andrewc at owl dot co dot uk>
Full name Andy Cooke <andrewc at owl dot co dot uk>
Date 2001-09-21 05:53:31 PDT
Message Hi Michael,

thanks for the suggestions. I managed to solve our Tigris 1.0.8 problems:
it turns out to be a bug in Helm's MDACookie.java rather than in Joist or

Sorry, the "Expires=" turned out to be a red herring. RFC 2109, concerning
"HTTP State Management Mechanism", specified capital letters for the
Set-Cookie header (see http://www.rfc-editor.org/, and see also last
October's RFC 2965 and RFC 2964 for new updates on Cookie, Cookie2 and

However most people seem to ignore RFC2109, and instead follow Netscape's

and this details the following syntax:
Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure

I notice that JServUtils.java in Joist (& Noodle & JServ) has a method that
encodes cookies according to Netscape's specification. So the response
intercepted by the Noodle proxy from the servlets would only ever contain
netscape-style cookies seems to simply create a Cookie object from this
response (using setMaxAge()), which ultimately would be translated again by
JServ into a Netscape cookie string (with "expires=")... I'm still not
completely sure how Joist's Noodle and JServ are working here, but I don't
think there are any bugs!

Our Tigris 1.0.8 problems instead came from the "domain=" attribute of the
MDAAuth cookie. Microsoft realised that it was possible for a website to
recieve cookies set by another host domain. So since Internet Explorer 5.01
(and in Opera?), it hasn't been possible to mix first and third party

Netscape's checks must be less rigourous:

When searching the cookie list for valid cookies, a comparison of the domain
attributes of the cookie is made with the Internet domain name of the host
from which the URL will be fetched. If there is a tail match, then the
cookie will go through path matching to see if it should be sent. "Tail
matching" means that domain attribute is matched against the tail of the
fully qualified domain name of the host. A domain attribute of "acme.com"
would match host names "anvil.acme.com" as well as "shipping.crate.acme.com.
" (from the Netscape link above)

MDACookie.java in Tigris 1.0.8's Helm had a method getCookieDomain() that
parsed a hostname specified in zone.properties to leave the last two parts
of the domain name. Our "www.jake.owl.co.uk" hostname would generate the
cookie domain attribute ".co.uk". So an MDAAuth cookie was sent to Internet
Explorer with a different domain name from JServ's cookie, and so IE blocked
this. In your case, hostnames were parsed into ".tigris.org", and so you
folks weren't experiencing problems. No wonder you must have been confused
by Colm's postings! I've managed to fix the problem now.

You might like to warn your Nibada component developers about this...

Thanks again for your help :-)

best wishes,

Andy Cooke

-----Original Message-----
From: Michael St.Ack [mailto:stack at collab dot net]
Sent: 20 September 2001 18:08
To: andrewc at owl dot co dot uk
Cc: apps-dev at projects dot collab dot net
Subject: Re: FW: cookie handling by joist and noodle

The request is passed through Noodle filters on the way in and again on
the way out. CopyCookies is one of these filters. In 108, see
org.tigris.helm.publ​ish.HelmNoodleResour​ces.properties for a listing.
org.tigris.helm.publ​ish.filter.HelmHeade​rs copies all but the connection
header onto the proxied request. It also adds some headers. Note how
org.joist.publish.fi​lters.CopyCookies and
org.tigris.helm.publ​ish.filters.CopyHead​ers2Response are run against the
  response back from the proxied server. CopyHeaders2Response does a
super-set of what CopyCookies does; it copies all headers that came from
the proxied request onto the response thats going back to the browser.

CopyCookies' purpose in life seems to be reformatting of cookie data, in
particular converting the expires portion of cookie data to a max-age
type spec. There may be a bug here in that it finds the 'expires'
portion of the cookie data by doing a String.equals rather than
String.equalsIgnoreCase if its possible that expires can be written w/ a
capital 'E' (See also earlier in the code where it does a
String.startsWith( )).

What happens if you edit
org.tigris.helm.publ​ish.HelmNoodleResour​ces.properties and take out
mention of CopyCookies? My notion is that CopyHeaders2Response will
copy over the Set-Cookies as they were written by the proxied server.
This may, in the long-run, break something else but it might give you
more clues as to whats going wrong.


Jon Stevens wrote:
> ------ Forwarded Message
> From: "Andy Cooke" <andrewc at owl dot co dot uk>
> Date: Thu, 20 Sep 2001 10:15:22 +0100
> To: <jon at latchkey dot com>
> Subject: FW: cookie handling by joist and noodle
> Hi Jon,
> You may remember me from occasional postings to the former helm/ releng
> lists. Here's a message I sent to the joist list yesterday - for some
> reason, I didn't see it on the list this morning... I *think* I found a
> small bug in Joist's CopyCookies.java, but I'll investigate further today!
> best wishes,
> Andy Cooke (Panasonic OWL)
> -----Original Message-----
> From: Andy Cooke [mailto:andrewc at owl dot co dot uk]
> Sent: 19 September 2001 18:48
> To: dev at joist dot tigris dot org
> Subject: cookie handling by joist and noodle
> Hi Folks,
> I've been trying to sort out problems we were having with the document
> downloads section of Tigris 1.0.8 (what a shame this is no longer open
> source!). As a reminder, Colm's last email to the former
> dev at releng dot tigris dot org list is posted at the end of this message.
> It turns out that the ProjectDocumentAdd servlet would post documents with
> "isPublic" set to false by default (should be true!?!), which forces the
> Apache server to make use of the MDARealmMask of the mod_auth_mda module.
> This module expects to receive a MDAAuth cookie. This cookie is set by
> ProjectDocumentList and ProjectDownloadList servlets, and sent with the
> response object back to the client during re-direction. The transparent
> HTTP proxy (Noodle) intercepts this, and Joist's CopyCookies.java filter
> does some manipulation of the cookies (I'm yet to figure this bit out...)
> So, mystified, I added a relay between my browsers and our site, to log
> HTTP being exchanged between client and browser. Pasted below are
> from the log of a session with Internet Explorer:
> ...<Logging on to Tigris 1.0.8 for the first time, and the server returns
> this>
> S1 HTTP/1.1 200 OK
> S1 Date: Wed, 19 Sep 2001 15:21:47 GMT
> S1 Server: Apache/1.3.17 (Unix) ApacheJServ/1.1.2 AuthMySQL/2.20
> S1 HelmLoginID: guest
> S1 Set-Cookie: JServSessionIdservle​ts=j2wa04io51; domain=.owl.co.uk;
> S1 Connection: close
> S1 Content-Type: text/html
> S1 X-Pad: avoid browser bug
> S1
> ...
> ...<then later, the IE client requests a download, and the MDAAuth cookie
> returned>
> C36 GET
> wnload HTTP/1.0
> C36 Accept: */*
> C36 Referer: http://owl-sqa.jake.​owl.co.uk/servlets/P​rojectDocumentList
> C36 Accept-Language: en-gb
> C36 Accept-Encoding: gzip, deflate
> C36 User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
> C36 Host: owl-sqa.jake.owl.co.uk
> C36 Proxy-Connection: Keep-Alive
> C36 Cookie: JServSessionIdservle​ts=j2wa04io51
> C36
> S36 HTTP/1.1 302 Found
> S36 Date: Wed, 19 Sep 2001 15:31:46 GMT
> S36 Server: Apache/1.3.17 (Unix) ApacheJServ/1.1.2 AuthMySQL/2.20
> S36 HelmLoginID: andrewc
> S36 Set-Cookie:
> MDAAuth=9cd15a061b21​128c58136492a1e06c3e​3ba8ba62andrewc@owl.​co.uk!2000!;
> expires=Thu, 20-Sep-2001 15:31:46 GMT; domain=.co.uk; path=/
> S36 Location: http://www.jake.owl.​co.uk/files/document​s/13/4/index.html
> S36 Connection: close
> S36 Content-Type: text/html; charset=iso-8859-1
> S36
> ...
> ... <something's gone wrong, as IE then hasn't correctly set the MDAAuth
> cookie. So the server chucks an MDABack cookie back at the client, with
> error page (in this case, the Document List) >
> C37 GET http://www.jake.owl.​co.uk/files/document​s/13/4/index.html HTTP/1.0
> C37 Accept: */*
> C37 Referer: http://owl-sqa.jake.​owl.co.uk/servlets/P​rojectDocumentList
> C37 Accept-Language: en-gb
> C37 Accept-Encoding: gzip, deflate
> C37 User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
> C37 Host: www.jake.owl.co.uk
> C37 Proxy-Connection: Keep-Alive
> C37 Cookie: JServSessionIdservle​ts=j2wa04io51
> C37
> S37 HTTP/1.1 302 Found
> S37 Date: Wed, 19 Sep 2001 15:31:46 GMT
> S37 Server: Apache/1.3.17 (Unix) ApacheJServ/1.1.2 AuthMySQL/2.20
> S37 Set-Cookie:
> s%2f13%2f4%2findex.h​tml%3frealm%3d20; path=/; domain=.jake.owl.co.uk
> S37 Location: http://owl-sqa.jake.​owl.co.uk/servlets/P​rojectDocumentList
> S37 Connection: close
> S37 Content-Type: text/html; charset=iso-8859-1
> S37
> ...
> Notice that when the MDAAuth cookie is set, the "expires=" field has been
> set. This is the only difference I can see between the three instances of
> Set-Cookie above.
> I think in old netscape HTTP, it should be "Expires=", but why isn't the
> "Max-Age=" field used instead? And where is the "expires=" written in the
> first place? Is this by Apache?
> Sorry for the long email. I realise that you probably are not making much
> use of Joist now, but any insights would be gratefully recieved :-)
> best wishes,
> Andy Cooke
> -------------- Colm McCarten's posting to dev at releng dot tigris dot org,
>>>>>>- Netscape seems to be the only browser that correctly handles the
> docs
>>>>>>area... (on Windows opera and IE open a new window with a duplicate
> of
> the
>>>>>>page). Also isn't there some problem about NS requiring a two-part
>>>>>​>COOKIE_DOMAIN? I would really appreciate any information anyone has
> on
>>>>>>since I haven't experienced problems in this area yet...
>>>>>This should definitly be made to work on IE ASAP.
>>>>IE and Mozilla 093 both work with HEAD from JR's sandbox.
>>>For the record, this isn't the case in 1.0.8 which makes me think it must
> be a
>>>recent change - anybody know to what? When?
>>I hate to repost but any takers on this? I know the functionality has
> to
>>nidaba so its tricky to see what has changed in CVS. Does anyone remember
>>addressing this bug? I don't see anything in IZ (although maybe related to
> #37)
>>Even a pointer as to what might need looked at? I can't see anything in
>>generated HTML that looks dodgy so I'm thinking it is an Apache config
> thing...
> This seems to be something to do with cookies - I'm logging the
> ProjectDocumentList's output and it seems fine but different clients are
> seeing
> different cookies - IE seeems to see a different domain path than NS (or
> Opera)
> and after accepting this still goes to a duplicate of the page...
> Anyone equally bothered by this?
> colm
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@rele​ng.tigris.org
> For additional commands, e-mail: dev-help at releng dot tigris dot org
> -------------------
> ------ End of Forwarded Message

To unsubscribe, e-mail: dev-unsubscribe@jois​t.tigris.org
For additional commands, e-mail: dev-help at joist dot tigris dot org

« Previous message in topic | 1 of 1 | Next message in topic »


Show all messages in topic

RE: FW: cookie handling by joist and noodle Andy Cooke <andrewc at owl dot co dot uk> Andy Cooke <andrewc at owl dot co dot uk> 2001-09-21 05:53:31 PDT
Messages per page: