Gitea over http, attempts to set cookie, error

So in my setup all communication with gitea is http, no ssh access. apache httpd acts as reverse proxy and terminates TLS, so all clients use https to talk to gitea via the reverse proxy.

our build automation solution is TeamCity, which checks repos for changes fairly frequently. TC talks to gitea via TLS over the proxy, despite being on the same host.

Every repo check generates an error in it’s logs similar to this:
WARN [TC: 20:21:23 getCurrentState: (root 1/1): "Backplane" {instance id=105, parent internal id=3, parent id=Backplane, description: ""}; 20:21:23 Loading VCS changes for "Backplane" {instance id=105, parent internal id=3, parent id=Backplane, description: ""}; 20:21:23 Task: "jetbrains.buildServer.util.executors.ScalingThreadPoolExecutor$RunnableFutureWrapper@4db8aeef"; VCS Periodical executor 2] - org.apache.http.client.protocol.ResponseProcessCookies - Invalid cookie header: "Set-Cookie: _csrf=8Gr51c27BINr0K43MtbLersTs8Y6MTU0OTY1NzI4Mzc1ODEyNTUzOQ%3D%3D; Path=/; Expires=Sat, 09 Feb 2019 20:21:23 GMT; HttpOnly". Invalid 'expires' attribute: Sat, 09 Feb 2019 20:21:23 GMT

This is starting to take a lot of room in log files and is just generally cause for concern, because I like to see this stuff working without errors. The cookie is set to expire exactly 1 day in the future. I don’t see anything wrong with it, it doesn’t look “invalid” to me. Any ideas?

Possible issue identified…

the expires= format might be slightly wrong. IT’s probably accepted by many things, but I’ve got something being strict and not liking this…

\See these two datetime strings…
Thu, 14 Feb 2019 18:37:22 GMT
Wed, 13-Feb-2019 18:59:03 GMT
The first string is from Gitea, the second is from Slack ( I just randomly chose a cookie from elsewhere)

IF Gitea would put those dashes in, I bet I’d stop getting these errors filling my logs.

but then again, without dashes around the month seems to be defined as the correct standard…