git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Bagas Sanjaya <bagasdotme@gmail.com>,
	git@vger.kernel.org, Daniel Stenberg <daniel@haxx.se>
Subject: Re: [PATCH] http: match headers case-insensitively when redacting
Date: Thu, 23 Sep 2021 17:56:42 -0400	[thread overview]
Message-ID: <YUz4Gr3o/Kobj10r@coredump.intra.peff.net> (raw)
In-Reply-To: <87lf3o5bdz.fsf@evledraar.gmail.com>

On Thu, Sep 23, 2021 at 03:22:04AM +0200, Ævar Arnfjörð Bjarmason wrote:

> >> Maybe for httpd config we can say that if mpm_prefork isn't loaded, load
> >> mpm_event and mod_http2.
> >
> > That doesn't work. We can say "is mpm_prefork" loaded, and indeed we
> > already do, in order to load mpm_prefork! That's because the module may
> > or may not be built-in, and if not, we have to load it (or some mpm
> > module). See 296f0b3ea9 (t/lib-httpd/apache.conf: configure an MPM
> > module for apache 2.4, 2013-06-09).
> >
> > But we have no way of knowing _which_ modules are available. It may just
> > be that "event" or "worker" (both of which support mod_http2) are
> > available close enough to everywhere that we can just guess.
> >
> >> And for testing both HTTP/2 and HTTP/1.1 did you mean sharing the same test
> >> code (with adjustments for each protocol)?
> >
> > Yes. I'd literally run the same battery of tests against both protocols
> > (see my other response to Taylor with a sketched-out example). I'm still
> > not sure it's entirely worth the effort, though. The underlying
> > transport should be pretty transparent to Git, with the exception of
> > things like debugging output.
> 
> Maybe I'm missing something, but it seems to me that trying to figure
> out if we support http v2 or not beforehand is the wrong thing to do in
> this case. Why don't we simply try to start the server, and fail and
> skip_all="sorry, no httpv2" if it fails?
> 
> Then have 2 test files:
> 
> t1234-http-v1.sh
> t1235-http-v2.sh

Sure. I was assuming we'd just have one server config (which _does_
work), but if we are spinning up two servers anyway for the separate
scripts, it would be easy enough to customize them. And I do think it
would make sense to do it in separate scripts.

And this dual-script thing might need to be repeated for others besides
t5551. I didn't look at which other ones might potentially benefit (or
if it's diminishing returns as we just add more basically-identical
tests that spend a bunch of CPU). This is why I say "it might not be
worth the effort".

> Where the latter includes the former (or is a symlink with a $0 check),
> or both include a library. Doing it this way also means you'll get a
> message you notice via "prove", since you won't run all v1 tests in one
> file, then skip some v2.

This does work oddly with GIT_TEST_HTTPD=Yes, which complains about
skipping (intentionally; it's how we notice when http setup code
breaks).  That might be acceptable, though, if the folks setting that
option (like me, or the linux CI jobs) are likely to have http2 support.

-Peff

  reply	other threads:[~2021-09-23 21:56 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-21 18:41 [PATCH] http: match headers case-insensitively when redacting Jeff King
2021-09-21 18:47 ` Jeff King
2021-09-21 20:14   ` Carlo Arenas
2021-09-21 20:40     ` Jeff King
2021-09-21 22:00   ` Daniel Stenberg
2021-09-22  2:32     ` Jeff King
2021-09-21 19:06 ` Eric Sunshine
2021-09-21 19:14   ` Jeff King
2021-09-22 19:10     ` Junio C Hamano
2021-09-21 21:20 ` Taylor Blau
2021-09-22  2:30   ` Jeff King
2021-09-22  2:32 ` Bagas Sanjaya
2021-09-22 20:11   ` Jeff King
2021-09-23  1:22     ` Ævar Arnfjörð Bjarmason
2021-09-23 21:56       ` Jeff King [this message]
2021-09-22 19:19 ` Junio C Hamano
2021-09-22 20:09   ` Jeff King
2021-09-22 20:51     ` Junio C Hamano
2021-09-22 21:18       ` Jeff King
2021-09-22 21:42         ` Junio C Hamano
2021-09-22 22:11           ` [PATCH v2] " Jeff King
2021-09-22 22:14             ` 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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=YUz4Gr3o/Kobj10r@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=bagasdotme@gmail.com \
    --cc=daniel@haxx.se \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).