Instead of auto-detection, let's make this very opt-in and explicit and add
a new client config option to "disabledHTTP2": true.



On Fri, Jul 15, 2016 at 10:00 AM, Mathieu Lonjaret <
[email protected]> wrote:

> To be clear, you only need to rebuild your CLI tools (not the server)
> with this CL patched in on top of master.
>
>
> On 15 July 2016 at 18:49, Mathieu Lonjaret <[email protected]>
> wrote:
> > Here's a possible work-around:
> > https://camlistore-review.googlesource.com/6896
> >
> > Can you please try it and let me know if it works for you?
> >
> >
> > On 15 July 2016 at 17:06, Mathieu Lonjaret <[email protected]>
> wrote:
> >> On 15 July 2016 at 16:56, Gergely Imreh <[email protected]> wrote:
> >>> On 15 July 2016 at 20:22, Tamás Gulácsi <[email protected]> wrote:
> >>>> 2016. július 14., csütörtök 18:57:27 UTC+2 időpontban Gergely Imreh a
> >>>> következőt írta:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I'm trying out camlistore, using the tip of the master branch, and
> run
> >>>>> into an issue with http/2, not letting me to connect to the server
> on the
> >>>>> command line, while the browser UI connection works fine.
> >>>>>
> >>>>> I'm packaging up camlistore as a Docker container to run on the
> resin.io
> >>>>> platform, basically being easily deployed to single board computer
> devices
> >>>>> (such as Raspberry Pi, Beaglebone, Intel Edison, etc...) The repo of
> the
> >>>>> container source is here:
> >>>>> https://github.com/resin-io-playground/camlistore-server
> >>>>>
> >>>>> On resin, the devices can be accessed over the net through a public
> device
> >>>>> URL. The address "https://<UUID>.resindevice.io" is proxied over
> VPN to the
> >>>>> device, to port 80. Thus I've set listen:":80" and
> >>>>> baseURL:"https://<UUID>.resindevice.io" in server-config.json. Over
> the web
> >>>>> UI I can connect, upload, change settings, everything.
> >>>>>
> >>>>> When using command line tools, on the other hand, I run into this
> error,
> >>>>> for example in the case of "camput file SOMEFILENAME":
> >>>>> Error putting file: Get https://<UUID>.resindevice.io: http2:
> unexpected
> >>>>> ALPN protocol ""; want "h2"
> >>>>>
> >>>>> That https proxy indeed does not have http/2 / ALPN enabled, does
> that
> >>>>> mean the command line tools cannot connect anymore?
> >>>>>
> >>>>> Looks like using the 0.8 release command line tools can work with
> the same
> >>>>> server just fine (server compiled either from 0.8 or master branch).
> Also,
> >>>>> using the master branch, can successfully use localhost dev server
> fine.
> >>>>>
> >>>>> Any ideas how to deal with this?
> >>>>>
> >>>>> Cheers,
> >>>>>    Greg
> >>>>
> >>>>
> >>>> Any difference by compiling with go1.7rc1 either 0.8 or master ?
> >>>> I think this has to be a proxy error.
> >>>> To locate it, can you check the camlistored whether it gets the
> connection
> >>>> at all when you try the cli tool? If yes, then that's strange :)
> >>>> If not, then maybe you have to degrade the protocol to HTTPS 1.1
> somehow at
> >>>> the proxy level, or by adding another proxy...
> >>>>
> >>>
> >>> Hi Tamas,
> >>>
> >>> I've tried to recompile the master with go 1.7rc1, but it does not
> >>> compile, fails for me in the very beginning with
> >>>
> >>> gopherjs for publisher error: exit status 1,
> >>> tmp/build-gopath-nosqlite/src/
> github.com/gopherjs/gopherjs/compiler/natives/runtime/runtime.go:11:14:
> >>> TheGoos not declared by package sys
> >>> ../../../../../../../../usr/lib/go/src/runtime/error.go:70:9: invalid
> >>> operation: e._type (variable of type *struct{_string *string}) has no
> >>> field or method string
> >>> exit status 1
> >>> make: *** [Makefile:6: all] Error 1
> >>>
> >>> I have not tried to recompile 0.8, since that was working before just
> >>> fine, the issue is with 0.9 and onwards.
> >>>
> >>> Not sure I understand your comment about degrading the protocol. The
> >>> proxy already tries to communicate over HTTP/1.1, what else is there
> >>> to change on the proxy? Running a http2 enabled curl on the web UI I
> >>> get the following exchange, showing the http2 request by curl, not
> >>> accepted by the server, falling back to HTTP/1.1 and following with
> >>> authentication (which means that curl at least can talk to the
> >>> camlistore server over http/1.1):
> >>>
> >>> $curl -I -v
> https://0fb549fe00f9a9c4ba96a45f349b525c4e36498835dc0533b202606bd43d81.resindevice.io/ui/
> >>> *   Trying 52.200.87.42...
> >>> * Connected to
> 0fb549fe00f9a9c4ba96a45f349b525c4e36498835dc0533b202606bd43d81.resindevice.io
> >>> (52.200.87.42) port 443 (#0)
> >>> * ALPN, offering h2
> >>> * ALPN, offering http/1.1
> >>> [SNIP]
> >>> * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
> >>> * ALPN, server did not agree to a protocol
> >>> [SNIP]
> >>> < HTTP/1.1 401 Unauthorized
> >>> HTTP/1.1 401 Unauthorized
> >>>
> >>> It all shows me that the issue is likely still be in the CLI tools
> >>> somewhere, not accepting protocol downgrading, but trying to force
> >>> http/2 even when not available?
> >>
> >> Yes. that is what I believe is happening too. I'm working on it.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Camlistore" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Camlistore" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to