git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Please document git-http-backend/Apache timeout interactions
@ 2016-02-21 22:17 Steinar H. Gunderson
  2016-02-21 23:29 ` Junio C Hamano
  0 siblings, 1 reply; 3+ messages in thread
From: Steinar H. Gunderson @ 2016-02-21 22:17 UTC (permalink / raw)
  To: git

Hi,

I am running git-http-backend behind Apache as suggested in
git-http-backend(1). However, what it fails to mention is that
git-fetch-pack seemingly can be very slow in sending its request.
Consequently, mod_reqtimeout (on by default, as I understand it)
kicks in as an anti-DoS measure, and the user sees a 408 (timeout)
error.

Seemingly the simplest fix is to turn off mod_reqtimeout in the vhost
serving git (potentially with some <IfModule> around it):

   RequestReadTimeout header=0 body=0

Would you consider adding this to the documentation?

Thanks!

/* Steinar */
-- 
Homepage: https://www.sesse.net/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Please document git-http-backend/Apache timeout interactions
  2016-02-21 22:17 Please document git-http-backend/Apache timeout interactions Steinar H. Gunderson
@ 2016-02-21 23:29 ` Junio C Hamano
  2016-02-21 23:34   ` Steinar H. Gunderson
  0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2016-02-21 23:29 UTC (permalink / raw)
  To: Steinar H. Gunderson; +Cc: git

"Steinar H. Gunderson" <sgunderson@bigfoot.com> writes:

> I am running git-http-backend behind Apache as suggested in
> git-http-backend(1). However, what it fails to mention is that
> git-fetch-pack seemingly can be very slow in sending its request.
> Consequently, mod_reqtimeout (on by default, as I understand it)
> kicks in as an anti-DoS measure, and the user sees a 408 (timeout)
> error.
>
> Seemingly the simplest fix is to turn off mod_reqtimeout in the vhost
> serving git (potentially with some <IfModule> around it):
>
>    RequestReadTimeout header=0 body=0
>
> Would you consider adding this to the documentation?

This feels 70% like "how to configure your Apache server when you
run site that is contacted by a client that is slow to talk?", that
is not necessarily specific to Git.

Also while it may make sense to tweak the timeout on the server
side, recommending to disable it altogether, instead of adjusting to
the typical requirement for a sane client, feels just wrong.

Also, are all requests from one client slow to start, or are only
some phases in the protocol exchange slow but not others?  If the
server side can tell which ones could be normally slow, selectively
loosening timeouts only for them might be more palatable, but I am
sensing that you are not suggesting such an approach.

For these reasons, I am on the fence.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Please document git-http-backend/Apache timeout interactions
  2016-02-21 23:29 ` Junio C Hamano
@ 2016-02-21 23:34   ` Steinar H. Gunderson
  0 siblings, 0 replies; 3+ messages in thread
From: Steinar H. Gunderson @ 2016-02-21 23:34 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Sun, Feb 21, 2016 at 03:29:56PM -0800, Junio C Hamano wrote:
> This feels 70% like "how to configure your Apache server when you
> run site that is contacted by a client that is slow to talk?", that
> is not necessarily specific to Git.

It's specific to Git in the sense that Git seemingly as a normal matter of
course posts very slowly to /git-upload-pack. Normal HTTP clients don't work
this way; they typically have their entire POST body ready before they decide
to make a request.

> Also while it may make sense to tweak the timeout on the server
> side, recommending to disable it altogether, instead of adjusting to
> the typical requirement for a sane client, feels just wrong.

True, although I have no idea what the right limits would be.

> Also, are all requests from one client slow to start, or are only
> some phases in the protocol exchange slow but not others?  If the
> server side can tell which ones could be normally slow, selectively
> loosening timeouts only for them might be more palatable, but I am
> sensing that you are not suggesting such an approach.

I know only of /git-upload-pack having this pattern, and it is the only one I
am seeing 408 errors for in my logs. It seems to fail very rarely (~0.2% of
all /git-upload-pack requests), but for some users, it's seemingly very
persistent.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-02-21 23:34 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-21 22:17 Please document git-http-backend/Apache timeout interactions Steinar H. Gunderson
2016-02-21 23:29 ` Junio C Hamano
2016-02-21 23:34   ` Steinar H. Gunderson

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 NNTP newsgroup(s).