On 17 July 2016 at 06:30, Gergely Imreh <[email protected]> wrote: > On 17 July 2016 at 01:31, Brad Fitzpatrick <[email protected]> wrote: >> On Fri, Jul 15, 2016 at 8:48 PM, Gergely Imreh <[email protected]> wrote: >>> >>> On 16 July 2016 at 01:50, Mathieu Lonjaret <[email protected]> >>> wrote: >>> > ACK, will do. >>> >>> Thanks, I've tried it out, and with the patchset 2 from your link, and >>> I can use the CLI tools. >>> >>> > >>> > On 15 July 2016 at 19:48, Brad Fitzpatrick <[email protected]> wrote: >>> >> Instead of auto-detection, let's make this very opt-in and explicit and >>> >> add >>> >> a new client config option to "disabledHTTP2": true. >>> >>> Just as an observation, all other tools handle protocol downgrade >>> transparently (browsers, curl, etc..). I think it would be a lot nicer >>> user expereice to have that sort of behaviour in camlistore too, >>> especially since the servers already give a hint whether or not they >>> handle http/2. >>> So for example, trying the curl commands in the `clients/curl` >>> examples (just the https versions to this particular server), it >>> automatically handles all this and can talk to the same camlistore >>> server over the same proxy, that the CLI tools cannot. >> >> Let's just say that given how much of an improvement HTTP/2 is >> (especially wrt to end-to-end encryption), the official stance of the >> project is to encourage its adoption as much as possible. Making it >> easy to downgrade would go contrary to that goal. So now you can tell >> resin.io to clean up their act, or you'll be leaving them for someone >> that does support HTTP/2 correctly ;) > > Well, since I'm working at resin.io (as developer evangelist), I won't > be leaving them for this tiny thing. :) But started the internal > discussion and have a ticket to upgrading to http/2, when it checks > out that it doesn't interfere with the other use cases (I think it > shouldn't be big of a deal, just due diligence)
Cool. let us know how it goes. > What you and Brad are saying makes sense regarding the official > stance, and I have no problem with it. Sill I wanted to mention, that > probably I'm forgiven thinking that this is a bug, not a feature, > since no HTTP/2 is mentioned on the entire Camlistore website (except > in code), nor was the original error message very helpful to signal a > design decision (as opposed to software failure). It would be probably > useful to make it "really official", if you don't want to run into > similar issues in the future of people misunderstanding (explicitly > highlighting on the website, mentioning in the "baseURL" section maybe > when you talk about reverse proxies, in the error message when can't > connect to the server over http/2). More doc is always good. Patches are welcome. :-) > Also, if it's an official stance, then maybe the entire changeset does > not make much sense to actually use from your point of view, as it is > a "temporary workaround of dubious quality" (forgive my paraphrasing). The first patchset of this CL was of dubious quality. If we eventually land the CL, it will just be about the disableHTTP2 option, which should not be of dubious quality. > I'm happy either way in the light of that (committed or not), as now I > understand your requirements more, all these qualifications were badly > needed. > >> As Mathieu said, we really want to encourage HTTP/2, which lets us make a >> bunch of assumptions which simplifies our code (e.g. previously we were >> planning our own batch blob PUT API, which is redundant with HTTP/2). >> Normally end-to-end HTTPS means you can do whatever you want and proxies >> won't interfere and break your code. If we know it's our code talking to our >> code, we know WebSockets will work for instance. Once you have a proxy >> involved, the proxy almost invariably shits over everything. > > Yeah, that's true, that proxies make things more complicated. For a > lot of use cases, they look are pretty inevitable, for better or > worse. Most web applications shouldn't be directly exposed to the net, > but have some more unified way (e.g. nginx) to take whatever is thrown > on it. I understand that it is not your main use case, and it > complicates things, so not saying you need to / should change > anything. Just what I see from experience. > > By the way, temporarily fixed things by adding a http/2/ALPN enabled > nginx proxy in front of the resin.ip proxy, seems to be working fine > (both CLI and web including websockets). In light of your previous comment about the CL, and this one about the proxy, are you saying that the disableHTTP2 option is of no value to you, and that you're better off with that additional proxy? Because I want to clean up some things in the client pkg before adding that option, and I'm in less of a hurry for doing so (i.e. I can finish some other things first), if the option itself is not really needed. >> We can totally do automatic downgrade if we wanted to (Go's net/http package >> does, for instance, and we used to go through it for all our HTTP), but we >> made the decision to hard-code http2 so when something doesn't work, the >> user has to very explicitly acknowledge they're running in an unsupported >> configuration and things may not work well. Your uploads may be very slow >> due to lack of batch requests in http2. Your web UI may not work due to lack >> of websockets. Etc. > > I see your point. In this case more information is very much needed. I > don't think there was a way beforehand for the user to "explicitly > acknowledge" anything, it just broke on the CLI, and worked just fine > on the web without any warning, in a sort of inconsistent experience. > Adding the config option as per changeset 2 does feel like a step > forward to the situation you describe indeed. And we can probably emit a hint to use that option when we detect that dialing is failing because of no ALPN or something like that. >> I care about Camlistore's existence over the coming decades (as services >> continues to shut down), so waiting out a temporary phase of HTTP/2 not >> being universally deployed is okay at the moment. Its adoption has been >> pretty impressive. I'm pretty sure resin.io will upgrade eventually. >> > > Yeah, deployment is a tricky thing. One watershed moment might be > Ubuntu 16.04.1 LTS, which will likely see the update from 14.04 LTS - > the openSSL shipped with the current (old) server cannot do ALPN even > if for example nginx does HTTP/2 just fine (this might be a case to > consider, that there can be one without the other, and camlistore > seems to need both) > > Cheers, > Greg > > -- > 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.
