Support GCLB Cookies
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 PMEdited
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
@Gabriel Terwesten 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 @Jim Borden'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.
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.