public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Jeff King <peff@peff•net>
To: Daniel Stenberg <daniel@haxx•se>
Cc: git@vger•kernel.org, Matthew John Cheetham <mjcheetham@outlook•com>
Subject: Re: [PATCH 0/3] test-suite fixes for upcoming curl 8.18.0
Date: Fri, 19 Dec 2025 03:04:09 -0500	[thread overview]
Message-ID: <20251219080409.GC3784564@coredump.intra.peff.net> (raw)
In-Reply-To: <sn7p46s1-4o20-q05n-173r-s6716s8145q6@unkk.fr>

On Thu, Dec 18, 2025 at 05:49:27PM +0100, Daniel Stenberg wrote:

> On Thu, 18 Dec 2025, Daniel Stenberg wrote:
> 
> > >  [3/3]: t5563: relax whitespace assumptions for unfolded headers
> 
> > I did not fully consider the impact this might have on users such as
> > you. Allow me to rework that a little bit further and get the former
> > white-space behavior back. Thanks!
> 
> I just merged a fix [1] into curl that should restore the unfolding behavior
> to match previous releases. It would be awesome if you could verify.
> 
> [1] = https://github.com/curl/curl/commit/9941e7c95bf26f00fd87888a

Thanks, I took a look at it. Unfortunately I think it only gets us
halfway there. It drops the extra space when folding this:

  printf 'Foo: bar\r\n'
  printf ' \r\n'
  printf ' baz\r\n'

which will yield:

  Foo: bar baz

and it fixes the first of Git's failing tests. But if we swap out the space for a tab
like this:

  printf 'Foo: bar\r\n'
  printf ' \r\n'
  printf '\tbaz\r\n'

then we get collapsed whitespace, but it's a tab. I.e.:

  Foo: bar\tbaz

(where "\t" is a literal tab). I think that does violate the standard
(which says it should become spaces). I think in most headers the
grammar allows OWS/RWS fields that are spaces or tabs, so in theory it
shouldn't matter. But I wouldn't be surprised if that causes some
surprises in the real world.

Sadly the input buffer to http_parse_headers() is const, so we can't
just write a space over the original tab. ;) But I think rather than
walking back to preserve that final leading whitespace byte, we could
just always add in our own space separately, like this:

diff --git a/lib/http.c b/lib/http.c
index ea62219542..eaa8bf73c2 100644
--- a/lib/http.c
+++ b/lib/http.c
@@ -4388,6 +4388,7 @@ static CURLcode http_parse_headers(struct Curl_easy *data,
     {
       /* preserve the whole original header piece size */
       size_t header_piece = consumed;
+      bool did_unfold = false;
 
       if(data->state.leading_unfold) {
         /* immediately after an unfold, keep only a single whitespace */
@@ -4398,17 +4399,18 @@ static CURLcode http_parse_headers(struct Curl_easy *data,
           blen--;
         }
         if(consumed) {
-          if(iblen > blen) {
-            /* take one step back */
-            consumed++;
-            buf--;
-            blen++;
-          }
           data->state.leading_unfold = FALSE; /* done now */
+          did_unfold = TRUE;
         }
       }
 
       if(consumed) {
+        if (did_unfold) {
+          result = curlx_dyn_addn(&data->state.headerb, " ", 1);
+          if(result)
+            return result;
+        }
+
         result = curlx_dyn_addn(&data->state.headerb, buf, consumed);
         if(result)
           return result;

-Peff

  reply	other threads:[~2025-12-19  8:04 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-18 12:11 [PATCH 0/3] test-suite fixes for upcoming curl 8.18.0 Jeff King
2025-12-18 12:13 ` [PATCH 1/3] t5551: handle trailing slashes in expected cookies output Jeff King
2025-12-18 12:18 ` [PATCH 2/3] t5563: add missing end-of-line in HTTP header Jeff King
2025-12-18 13:41   ` Matthew John Cheetham
2025-12-19  7:32     ` Jeff King
2025-12-18 12:22 ` [PATCH 3/3] t5563: relax whitespace assumptions for unfolded headers Jeff King
2025-12-18 13:45   ` Matthew John Cheetham
2025-12-18 12:37 ` [PATCH 0/3] test-suite fixes for upcoming curl 8.18.0 Daniel Stenberg
2025-12-18 16:49   ` Daniel Stenberg
2025-12-19  8:04     ` Jeff King [this message]
2025-12-19  8:47       ` Daniel Stenberg
2025-12-19 23:23         ` Jeff King
2025-12-20  2:14           ` Junio C Hamano
2025-12-19  7:50   ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251219080409.GC3784564@coredump.intra.peff.net \
    --to=peff@peff$(echo .)net \
    --cc=daniel@haxx$(echo .)se \
    --cc=git@vger$(echo .)kernel.org \
    --cc=mjcheetham@outlook$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox