All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Cc: Jon Simons <jon@jonsimons.org>, Jonathan Tan <jonathantanmy@google.com>
Subject: [BUG?] protocol.version=2 sends HTTP "Expect" headers
Date: Wed, 31 Oct 2018 12:03:53 -0400	[thread overview]
Message-ID: <20181031160353.GA17267@sigill.intra.peff.net> (raw)

Since 959dfcf42f (smart-http: Really never use Expect: 100-continue,
2011-03-14), we try to avoid sending "Expect" headers, since some
proxies apparently don't handle them well. There we have to explicitly
tell curl not to use them.

The exception is large requests with GSSAPI, as explained in c80d96ca0c
(remote-curl: fix large pushes with GSSAPI, 2013-10-31).

However, Jon Simons noticed that when using protocol.version=2, we've
started sending Expect headers again. That's because rather than going
through post_rpc(), we push the stateless data through a proxy_state
struct. And in proxy_state_init(), when we set up the headers, we do not
disable curl's Expect handling.

So a few questions:

  - is this a bug or not? I.e., do we still need to care about proxies
    that can't handle Expect? The original commit was from 2011. Maybe
    things are better now. Or maybe that's blind optimism.

    Nobody has complained yet, but that's probably just because v2 isn't
    widely deployed yet.

  - if it is a bug, how can we handle it like the v0 code? There we
    enable it only for GSSAPI on large requests. But I'm not sure we can
    know here whether the request is large, since we're inherently just
    streaming through chunked data. It looks like post_rpc tries to read
    a single packet first, and considers anything over 64k to be large.

  - alternatively, should we just leave it on for v2, and provide a
    config switch to disable it if you have a crappy proxy? I don't know
    how widespread the problem is, but I can imagine that the issue is
    subtle enough that most users wouldn't even know.

I think I've convinced myself that we probably do need to do the "peek
at the first packet" thing like post_rpc() does, but I think it might be
tricky with the way the proxy_state code is structured.

Thoughts from people with more HTTP knowledge/experience?

-Peff

             reply	other threads:[~2018-10-31 16:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-31 16:03 Jeff King [this message]
2018-11-01  0:48 ` [BUG?] protocol.version=2 sends HTTP "Expect" headers brian m. carlson
2018-11-01 18:35   ` 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=20181031160353.GA17267@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=jon@jonsimons.org \
    --cc=jonathantanmy@google.com \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.