Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

Re: [PATCH 2/2] remote-curl: let users turn off smart http

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:54:49

Jeff King [off-list ref] writes:
On Thu, Sep 20, 2012 at 10:53:15AM -0700, Junio C Hamano wrote:
quoted
Jeff King [off-list ref] writes:
quoted
I added the config item as remote.foo.smarthttp. You could also allow
"http.$url.smart" (and just "http.smart", for that matter), which could
be more flexible if you have multiple remotes pointing to the same
broken server.
What would the user experience be when we introduce "even smarter"
http server protocol extension?  Will we add remote.foo.starterhttp?
I would hope that it would actually be negotiated reliably at the
protocol level so we do not have to deal with this mess again.
The original dumb vs smart was supposed to be "negotiated reliably
at the protocol level", no?  Yet we need this band-aid, so...
quoted
Perhaps

    remote.$name.httpvariants = [smart] [dumb]

to allow users to say "smart only", "dumb only", or "smart and/or
dumb" might be more code but less burden on the users.
I don't mind that format if we are going that direction, but is there
anybody who actually wants to say "smart only?"
With 703e6e7 reverted, we take a failure from the initial smart
request to mean the server is simply not serving, so "smart only" to
fail quickly without trying dumb fallback is not needed.  "smart
only" to say "I wouldn't want to talk to dumb-only server---I do not
have infinite amount of time, and I'd rather try another server" is
still a possibility, but likely not worth supporting.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help