* git over https and http 1.1
@ 2011-05-18 12:46 Nir.Friedman
2011-05-19 20:31 ` Drew Northup
0 siblings, 1 reply; 6+ messages in thread
From: Nir.Friedman @ 2011-05-18 12:46 UTC (permalink / raw)
To: git
I am using git with https as the transport protocol.
Response times were around 30 seconds before apache started processing the backend command.
I added the flags - BrowserMatch "git" downgrade-1.0 force-response-1.0
to the apache conf file, and response times were fast.
This seems to mean that the libcurl library is not dealing correctly with HTTP 1/1 over SSL. Is this the best fix?
If so, maybe appropriate documentation should be added to the git setup docs.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git over https and http 1.1
2011-05-18 12:46 git over https and http 1.1 Nir.Friedman
@ 2011-05-19 20:31 ` Drew Northup
2011-05-19 20:36 ` Daniel Stenberg
0 siblings, 1 reply; 6+ messages in thread
From: Drew Northup @ 2011-05-19 20:31 UTC (permalink / raw)
To: Nir.Friedman; +Cc: git
On Wed, 2011-05-18 at 08:46 -0400, Nir.Friedman@greenhouse.lotus.com
wrote:
> I am using git with https as the transport protocol.
> Response times were around 30 seconds before apache started processing the backend command.
> I added the flags - BrowserMatch "git" downgrade-1.0 force-response-1.0
> to the apache conf file, and response times were fast.
> This seems to mean that the libcurl library is not dealing correctly with HTTP 1/1 over SSL. Is this the best fix?
> If so, maybe appropriate documentation should be added to the git setup docs.--
Sounds a little drastic to me... Perhaps to find out what's going on you
might set up a test repo behind an STunnel instance and have a look at
the TCP/HTTP stream between them?
Perhaps Git+libcurl isn't using keep-alive? I'd have to check the code.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git over https and http 1.1
2011-05-19 20:31 ` Drew Northup
@ 2011-05-19 20:36 ` Daniel Stenberg
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Stenberg @ 2011-05-19 20:36 UTC (permalink / raw)
To: Drew Northup; +Cc: Nir.Friedman, git
On Thu, 19 May 2011, Drew Northup wrote:
> Perhaps Git+libcurl isn't using keep-alive? I'd have to check the code.
They do. HTTP 1.1 even does "keep-alive" by default...
--
/ daniel.haxx.se
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git over https and http 1.1
2011-05-18 12:30 Nir Friedman
2011-05-18 12:41 ` Daniel Stenberg
@ 2011-05-19 14:39 ` Peter Vereshagin
1 sibling, 0 replies; 6+ messages in thread
From: Peter Vereshagin @ 2011-05-19 14:39 UTC (permalink / raw)
To: Nir Friedman; +Cc: git
You'll never silence the voice of the voiceless, Nir!
2011/05/18 15:30:18 +0300 Nir Friedman <nirfri@hotmail.com> => To git@vger.kernel.org :
NF> I am using git with https as the transport protocol.
NF> Response times were around 30 seconds before apache started processing the
NF> backend command.
NF> I added the flags [BrowserMatch "git" downgrade-1.0
NF> force-response-1.0] to the apache conf file, and response times were fast.
NF> This seems to mean that the libcurl library is not dealing correctly with
NF> HTTP 1/1 over SSL. Is this the best fix?
It's very unlikely for curl to work bad with https.
Isn't it a DNS-related delay?
NF> If so, maybe appropriate documentation should be added to the git setup
NF> docs.
73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB 12F8 0CE1 4AAC A0E2 6627)
--
http://vereshagin.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git over https and http 1.1
2011-05-18 12:30 Nir Friedman
@ 2011-05-18 12:41 ` Daniel Stenberg
2011-05-19 14:39 ` Peter Vereshagin
1 sibling, 0 replies; 6+ messages in thread
From: Daniel Stenberg @ 2011-05-18 12:41 UTC (permalink / raw)
To: Nir Friedman; +Cc: git
On Wed, 18 May 2011, Nir Friedman wrote:
> I am using git with https as the transport protocol. Response times were
> around 30 seconds before apache started processing the backend command.
Can you please be a bit more elaborate on exactly what took that much time?
What is a "response time" in this context?
> I added the flags [BrowserMatch "git" downgrade-1.0
> force-response-1.0] to the apache conf file, and response times were fast.
How fast is "fast" compared to the previous 30 seconds?
> This seems to mean that the libcurl library is not dealing correctly with
> HTTP 1/1 over SSL.
I don't think that's what it means but I have to little data to go on. What
libcurl version are you using on what platform?
--
/ daniel.haxx.se
^ permalink raw reply [flat|nested] 6+ messages in thread
* git over https and http 1.1
@ 2011-05-18 12:30 Nir Friedman
2011-05-18 12:41 ` Daniel Stenberg
2011-05-19 14:39 ` Peter Vereshagin
0 siblings, 2 replies; 6+ messages in thread
From: Nir Friedman @ 2011-05-18 12:30 UTC (permalink / raw)
To: git
I am using git with https as the transport protocol.
Response times were around 30 seconds before apache started processing the
backend command.
I added the flags [BrowserMatch "git" downgrade-1.0
force-response-1.0] to the apache conf file, and response times were fast.
This seems to mean that the libcurl library is not dealing correctly with
HTTP 1/1 over SSL. Is this the best fix?
If so, maybe appropriate documentation should be added to the git setup
docs.
-Nirf
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-05-19 20:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-18 12:46 git over https and http 1.1 Nir.Friedman
2011-05-19 20:31 ` Drew Northup
2011-05-19 20:36 ` Daniel Stenberg
-- strict thread matches above, loose matches on Subject: below --
2011-05-18 12:30 Nir Friedman
2011-05-18 12:41 ` Daniel Stenberg
2011-05-19 14:39 ` Peter Vereshagin
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.