Fossil Forum

"Connection:" HTTP header containing multiple values
Login

"Connection:" HTTP header containing multiple values

Chronological

"Connection:" HTTP header containing multiple values

(1) By Florian Balmer (florian.balmer) on 2024-04-20 15:15:50 [source]

My Fossil client is the latest trunk [33fe72ca75] with all the recent Apache 2.4.59/mod_cgi fixes.

When cloning and sync'ing with my Apache web server, I get one or more "content-length" missing from 200 keep-alive reply warnings (introduced by [f4ffefe708]) and an empty repository.

The server replies are like this:

HTTP/1.1 200 OK
Date: Sat, 20 Apr 2024 14:48:25 GMT
Server: Apache
Cache-control: no-cache
X-Frame-Options: SAMEORIGIN
Upgrade: h2,h2c
Connection: Upgrade, close
Content-Type: application/x-fossil-uncompressed

Fossil fails to parse the "Connection:" HTTP header with multiple values and doesn't close the connection.

This patch branch fixes the problem for me.

Not sure if this is too specific to be merged. If merging is considered, please verify if my lazy approach to allow both spaces and commas as separators for multiple HTTP header values is fine, or if the code should be more scrict and allow only commas as separators (but with optional surrounding spaces on either end, if I get that right).

(2) By Stephan Beal (stephan) on 2024-04-20 16:06:23 in reply to 1 [link] [source]

Fossil fails to parse the "Connection:" HTTP header with multiple values and doesn't close the connection. This patch branch fixes the problem for me.

Just FYI, that's running on my server now. So far, so good.

(3) By Richard Hipp (drh) on 2024-04-21 15:50:07 in reply to 2 [link] [source]

Justification for the simplification at check-in 77f25829d2f9f7b9:

  1. Less code, so less to go wrong. In particular, less chance of an array-bounds overflow.

  2. There is no harm in the client closing the connection even if the server says "Connection: keep-alive". But failures occur if Content-Length is omitted and the client thinks the connection is "keep-alive" but the server thinks it is "close". In other words, a false detection of "close" is harmless, but a missed detection of "close" can lead to failures. Hence the parsing of "Connection:" does not need to be perfect, as long as it never misses a "Connection: close", which the new code will not.

(4) By Florian Balmer (florian.balmer) on 2024-04-22 12:17:23 in reply to 3 [link] [source]

Only question is: will your solution be fast enough? ;-)