Support GCLB Cookies

Description

This forum post outlines a GCLB cookie, used by load-balancers to manage sticky sessions.
https://forums.couchbase.com/t/couldnt-parse-expires-in-cookie/34932/4

My guess is that all we need to do is to copy it in to subsequent requests, if we see it.

ADDED: It sounds as if my guess was wrong.  Apparently we need to parse the expiry date and to stop using a cookie when it expires.

I'm creating separate sub-task tickets for each of the platforms because each has a different implementation for cookie handling.

This task, the parent for all the subtasks, should be the focus for discussion of how the cookies should be handled.  Use the subtasks to discuss platform specific implementation.

 

is parent task of

Activity

Jim Borden December 14, 2022 at 11:05 PM

Leave it to Google to choose a format not even in the RFC.  I think we should also file a bug with them for not conforming.  Should we also support the obsolete RFC850 while we are at it? RFC6265 says the following:

HTTP/1.1 clients and servers that parse the date value MUST accept
   all three formats (for compatibility with HTTP/1.0), though they MUST
   only generate the RFC 1123 format for representing HTTP-date values
   in header fields.

Blake Meike December 13, 2022 at 10:36 PM
Edited

Java is doing the following:
It passes the entire value of a Set-Cookie header to LiteCore.  E.g., from the example above:

GCLB=COWjp4rwlqauaQ; path=/; HttpOnly; expires=Tue, 22-Nov-2022 07:21:38 GMT

Then, to any subsequent request, sent before the connection is completely open, it adds all of the cookies that it gets from LiteCore. It expects them in the format:

<cookie-name>=<cookie-value>(;<cookie-name>=<cookie-value>)*

... or from the above example:

GCLB=COWjp4rwlqauaQ;anotherCookie=anotherValue

Note that everything except the name and the value have been truncated.

My conclusion is that Java is doing this correctly: It gives Lite Core the entire cookie and asks it for cookies before sending requests. As long Lite Core gives Java the correct cookies, Java will pass them on in the Open request.

Pasin Suriyentrakorn December 10, 2022 at 5:55 AM

Reference links :

https://www.rfc-editor.org/rfc/rfc6265#section-4.1.1

https://www.rfc-editor.org/rfc/rfc2616#section-3.3.1 (Referred by RFC 6265 as linked above)

The three formats from the above doc :

  • Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123

  • Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036

  • Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

GCLB Format :

Set-Cookie: GCLB=COWjp4rwlqauaQ; path=/; HttpOnly; expires=Tue, 22-Nov-2022 07:21:38 GMT

Mozilla doc (Seem to be inline with RFC 1123): 
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date

Jim Borden November 30, 2022 at 9:58 AM

Yes that's exactly right.  To fix this a more robust parsing method is needed.

Gabriel Terwesten November 29, 2022 at 11:48 AM

From 's comment in the forum thread, I take that CBL already stores and sends cookies with subsequent requests. I think the GCBL cookies are getting dropped because CBL cannot parse the date format. That's in line with RFC 6265, which says that you should ignore cookies if the expiry date cannot be parsed. But the algorithm for parsing dates, described in that RFC, is more complex and allows for more format variations than what CBL implements.

Fixed
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Story Points

Components

Affects versions

Priority

Instabug

Open Instabug

PagerDuty

Sentry

Zendesk Support

Created November 28, 2022 at 11:26 PM
Updated February 9, 2023 at 3:20 AM
Resolved December 14, 2022 at 2:27 AM
Instabug